Anthonny Quérouil

How Workerify's Vite Plugin and Core Library Work Together: A Deep Dive

Anthonny Quérouil — Tue, 16 Sep 2025 00:00:00 GMT

Building modern web applications with Service Workers can be complex. Workerify’s goal isn’t to simplify every aspect of Service Worker development, but rather to make it straightforward to create API-like endpoints directly in the browser. By providing a Fastify-like router that runs entirely inside a Service Worker, Workerify makes this specific use case both easy and powerful. In this post, we’ll explore Workerify’s architecture and how its Vite plugin and core library work hand in hand.

Architecture Overview

Workerify is made of two main packages:

@workerify/lib: the core routing library, handling request matching and processing
@workerify/vite-plugin: a Vite plugin that manages Service Worker registration and build-time optimizations

These two communicate through the BroadcastChannel API, letting your app define routes while the Service Worker intercepts and handles HTTP traffic.

The Journey of a Request

Let’s follow how a request flows through the system.

1. Initial Setup: The Vite Plugin

When you add the Workerify plugin to your Vite config:

// vite.config.ts
import workerify from '@workerify/vite-plugin';

export default defineConfig({
  plugins: [workerify()]
});

The plugin takes care of several things:

Generates a Service Worker file at /workerify-sw.js
Provides a virtual module (virtual:workerify-register) for easy registration
Handles both dev and build modes, served from memory in dev, emitted as a build asset in prod

2. Application Initialization

In your app code, you register the Service Worker and define routes:

import { registerWorkerifySW } from 'virtual:workerify-register';
import Workerify from '@workerify/lib';

await registerWorkerifySW();

const app = new Workerify({ logger: true });

app.get('/todos', async () => JSON.stringify(todos));

app.post('/todos', async (request, reply) => {
  todos.push(request.body?.todo);
  reply.headers = { 'HX-Trigger': 'todos:refresh' };
});

await app.listen();

3. The Registration Dance

When app.listen() runs:

A unique consumer ID is created
The instance registers with the Service Worker at /__workerify/register
Routes are broadcast via BroadcastChannel
The Service Worker acknowledges the registration

4. The Service Worker: Traffic Controller

The Service Worker, generated by the plugin, maps clients to consumers and routes. When a fetch event occurs, it looks for a matching route and, if found, hands off processing to the right consumer through the channel.

5. Request Pipeline

Interception — Service Worker catches the request
Route Matching — Finds the right handler
Broadcast — Sends request details to the consumer
Processing — Consumer runs the handler
Response — Returned via BroadcastChannel
Delivery — Service Worker replies to the browser

Multi-Tab Support

Service Workers are shared across tabs. Workerify ensures isolation by giving each tab its own consumer ID and routes. Closing a tab automatically cleans up its routes, avoiding conflicts between tabs.

The Communication Protocol

Workerify relies on a simple, well-defined protocol over BroadcastChannel:

Route registration:

{
  type: 'workerify:routes:update',
  consumerId, routes
}

Request handling:

{
  type: 'workerify:handle',
  id,
  consumerId,
  request
}

Response delivery:

{
  type: 'workerify:response',
  id,
  status,
  headers,
  body
}

Debugging:

{ type: 'workerify:routes:list' },
{ type: 'workerify:clients:list' }

Build-Time Optimizations

The Vite plugin improves both dev and production workflows:

Pre-compiled templates for the Service Worker
Virtual module generation for registration code
Automatic base path handling
Memory serving in dev for faster updates

Why This Architecture?

Unlike traditional Service Worker setups, Workerify removes boilerplate and gives developers:

A familiar API (Fastify-like)
Zero network latency, requests handled in-browser
SPA-friendly design, perfect with HTMX
Smooth dev experience, hot reload and route updates without reinstalling the SW
Full TypeScript support

Performance Considerations

Minimal overhead with BroadcastChannel
Lazy route matching only when needed
Automatic cleanup of closed tabs
Memory efficiency by storing routes once in the Service Worker

Practical Example: A Todo App

import { registerWorkerifySW } from 'virtual:workerify-register';
import Workerify from '@workerify/lib';
import htmx from 'htmx.org';

await registerWorkerifySW();

const app = new Workerify({ logger: true });
const todos: string[] = [];

app.get('/todos', async () =>
  `${todos.map(t => `${t}
`).join('')}`
);

app.post('/todos', async (request, reply) => {
  todos.push(request.body?.todo);
  reply.headers = { 'HX-Trigger': 'todos:refresh' };
  return { success: true };
});

await app.listen();
htmx.trigger('#app', 'workerify-ready');

Start now

Getting started with Workerify is straightforward. You can scaffold a new project in seconds with:

npx @workerify/create-htmx-app

This will generate a ready-to-use setup with Vite, HTMX, and Workerify so you can start experimenting right away.

Conclusion

Workerify makes Service Worker routing simple and powerful by:

Separating route definition (lib) from SW management (plugin)
Using BroadcastChannel for fast communication
Handling multi-tab isolation automatically
Offering a familiar, developer-friendly API

This design opens the door to offline-first apps, zero-latency SPAs, and new client-side architectures. Workerify is still evolving, but it’s a useful starting point for experimenting with Service Workers in new ways — and it can even serve as a stepping stone toward simpler application models, especially those built with HTMX.

👉 Try it out, experiment with your own projects, and feel free to share your feedback and experiences with me, I’d love to hear how you use Workerify! A fresh Discord is available if you’d like to join and share with me 😁

How to use accounts-ui with Elm and Meteor in 10 minutes

Anthonny Quérouil — Wed, 24 Jun 2020 00:00:00 GMT

With Meteor you can quickly add an account management system using the packages accounts-ui and accounts-password. It is really useful for prototyping your application, before going deeper and creating your own design for the accounts management (login, register…). In this post we will see how to use these packages inside our Elm / Meteor application.

If you want to play with the code, you can use my starter kit https://github.com/anthonny/meteor-elm-starter-kit. You will find details about this setup here

git clone https://github.com/anthonny/meteor-elm-starter-kit.git meteor-elm-app
cd meteor-elm-app
meteor npm i

Table of Contents

Add the accounts-ui widget in our app
- The Meteor side
- The Elm side
Manage the possible states
- The Elm side
- The Meteor side
Synchronize the two applications
- The Elm side
- The Meteor side
Conclusion

Add the accounts-ui widget in our app

The Meteor side

We will use the accounts-ui, the accounts-password and the jquery packages. So we will install the following elements:

# under meteor-elm-app
meteor add accounts-ui accounts-password jquery
meteor npm i jquery

Now we will be able to use the Template.loginButtons in our code to display the login form.

We want to manage the visibility of the form inside our Elm application. A custom element is the perfect feature to do that, we will be able to use Html.node in Elm to work with it.

We can create a file imports/ui/accounts-ui.ts

import { Blaze } from 'meteor/blaze';
import { Template } from 'meteor/templating';

export class AccountsUi extends HTMLElement {
    view: Blaze.View;
    container: HTMLDivElement;
    constructor() {
        super();
        this.container = document.createElement('div');
        this.view = Blaze.render(Template.loginButtons, this.container);
    }
    connectedCallback() {
        this.appendChild(this.container);
    }
    disconnectedCallback() {
        if (this.view) {
            Blaze.remove(this.view);
        }
    }
}

And we can use it in the file client/main.ts and define a custom element called accounts-ui

import { AccountsUi } from '/imports/ui/accounts-ui';
import { init } from 'meteor/elm-app';
import { Meteor } from 'meteor/meteor';

customElements.define('accounts-ui', AccountsUi);

Meteor.startup(() => {
    const ports = init({
        node: document.getElementById('main'),
        flags: {},
    });
});

The Elm side

With the Html.node, it is really easy to use WebComponents inside your Elm application.

Lets modify our main file packages/elm-app/app/src/Main.elm

import Html exposing (Html, div, node, text)


view : Model -> Html msg
view model =
    div []
        [ node "accounts-ui" [] []
        , text model
        ]

We can now start our Meteor application meteor npm start and open http://localhost:3000 You should see the login form from accounts-ui:

And if your click on Sign in:

In maybe 5 minutes we have added the account management in our application. But we still need to inform our Elm application about the state of the authentication.

Manage the possible states

The Elm side

There are three states we need to handle:

when the user is logged in,
when the user is not logged in, anonymous,
when the user is logging in, it occurs when the application starts and when the user submit the login form.

So we can change our Model to:

type Model
    = LoggedIn String
    | LoggingIn
    | Anonymous

The LoggedIn state will have an associated String: the email of the current user.

Now we can adapt our view function:

view : Model -> Html msg
view model =
    div []
        [ node "accounts-ui" [] []
        , case model of
            Anonymous ->
                text "anonymous"

            LoggedIn email ->
                text <| "Hello " ++ email

            LoggingIn ->
                text "Logging in..."
        ]

Our code does not compile yet, we have to fix the init function. We have two possible states during the init phase:

Anonymous
LoggingIn

We can manage these states with a simple boolean isLoggingIn in our type Flags:

type alias Flags =
    { isLoggingIn : Bool
    }


main : Program Flags Model msg
main =
    Browser.element
        { init = init
        , view = view
        , update = update
        , subscriptions = subscriptions
        }


init : Flags -> ( Model, Cmd msg )
init flags =
    ( if flags.isLoggingIn then
        LoggingIn

      else
        Anonymous
    , Cmd.none
    )

The Meteor side

If you start the application meteor npm start, you should see this error:

The message is clear, we must define the isLoggingIn in our flags object.

We modify the interface Flags in the file index.ts:

interface Flags {
    isLoggingIn: boolean;
}

And we can use it in the client/main.ts:

Meteor.startup(() => {
    const ports = init({
        node: document.getElementById('main'),
        flags: {
            isLoggingIn: Meteor.loggingIn(),
        },
    });
});

You should see this content:

The problem is if you create a new user and you logging in, the state does not change. It only changes if you refresh the page. To synchronize our Elm application with Meteor, we will use ports.

Synchronize the two applications

The Elm side

The Meteor application must indicate to the Elm application when

the user is logging in,
the user is logged in,
the user is logged out

In our file packages/elm-app/app/src/Main.elm, we will add three ports:

port loggingIn : (() -> msg) -> Sub msg


port loggedIn : (String -> msg) -> Sub msg


port loggedOut : (() -> msg) -> Sub msg

We will create three messages, one message per event

type Msg
    = GotLoggingIn
    | GotLoggedIn String
    | GotLoggedOut

And we have to adapt the update function and to define subscriptions:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        GotLoggingIn ->
            ( LoggingIn, Cmd.none )

        GotLoggedIn email ->
            ( LoggedIn email, Cmd.none )

        GotLoggedOut ->
            ( Anonymous, Cmd.none )


subscriptions : Model -> Sub Msg
subscriptions _ =
    Sub.batch
        [ loggingIn (\_ -> GotLoggingIn)
        , loggedIn GotLoggedIn
        , loggedOut (\_ -> GotLoggedOut)
        ]

To finish we have to update the definition of our type Ports in packages/elm-app/:

export interface Ports {
    loggingIn?: {
        send: (nothing: null) => void;
    };
    loggedIn?: {
        send: (username: string) => void;
    };
    loggedOut?: {
        send: (nothing: null) => void;
    };
}

The Meteor side

On the Meteor side, we will use the function Tracker.autorun to send messages to the Elm application each time the state of the authentication changes.

// ...
import { Tracker } from 'meteor/tracker';

// ...
Meteor.startup(() => {
    const ports = init({
        node: document.getElementById('main'),
        flags: {
            isLoggingIn: Meteor.loggingIn(),
        },
    });

    Tracker.autorun(() => {
        if (Meteor.loggingIn()) {
            console.log('Loggind in...');
            ports.loggingIn?.send(null);
        } else if (Meteor.user()) {
            console.log('Connected');
            ports.loggedIn?.send(Meteor.user()?.emails?.[0].address || '');
        } else {
            console.log('Not connected');
            ports.loggedOut?.send(null);
        }
    });
});

Now you should see the state up-to-date in the Elm application when you play with the authentication.

Your browser does not support the video tag.

Conclusion

With Meteor it is easy to add an account management system, thanks to accounts-ui and the combination of Elm with the Custom Elements makes the integration simple.

But I think that one day you will have to create your own UI for your forms (login, register…), luckily it will be the topic of my next post.

If you liked this post, do not hesitate to share it on your favorite social networks and if you are interested by this kind of content, you can follow me on twitter @anthonny_q.

If you have any feedbacks, comments are open 😘

How I use Meteor, Elm and Tailwindcss together

Anthonny Quérouil — Wed, 17 Jun 2020 00:00:00 GMT

I have worked with Elm last year and honestly it was an great experience. I really liked it and I would like to use Elm in all my new projects. But I also like Meteor and three weeks ago I started using it again. I discovered Meteor in 2015, I gave a talk about it (https://www.youtube.com/watch?v=AxIvfQXTqVo) and it still feels like "Wow!" when you start a project. So in this post I will explain how I make the two work together and how to add Tailwindcss for the UI part (I love Tailwindcss too 😍), from scratch. I will also explain how to link an existing project to Meteor with a Todo app.

Prerequisite

You only need two things:

Your favourite IDE (VSCode with the Elm extension fits very well)
A browser

You don’t need to install NPM, Node or Mongo. All this stuff is already packaged in Meteor environment.

So to run a NPM command we will use meteor npm xxx, and for Mongo, we will use meteor mongo.

So let’s begin 😁

Meteor

Install Meteor

Here are the commands to install Meteor on OSX/Linux and Windows OSX / Linux

# OSX/Linux
curl https://install.meteor.com/ | sh

# Windows
choco install meteor

For more information about the installation, please refer to the official documentation here https://www.meteor.com/install

Create a project

Let’s start by creating an empty project

meteor create meteor-elm-app --bare
cd meteor-elm-app

This --bare option will create an empty project with static-html instead of blaze and without autopublish and insecure.

For more information about the command create, follow the link to the documentation

Add typescript

Adding Typescript is really simple. Just run these two commands

# under meteor-elm-app
meteor add typescript
meteor npm i -D @types/meteor @types/mocha

Create a tsconfig.json under the directory meteor-elm-app

{
    "compilerOptions": {
      /* Basic Options */
      "target": "es2018",
      "module": "esNext",
      "lib": ["esnext", "dom"],
      "allowJs": true,
      "checkJs": false,
      "incremental": false,
      "noEmit": true,

      /* Strict Type-Checking Options */
      "strict": true,
      "noImplicitAny": true,
      "strictNullChecks": true,

      /* Additional Checks */
      "noUnusedLocals": true,
      "noUnusedParameters": true,
      "noImplicitReturns": false,
      "noFallthroughCasesInSwitch": false,

      /* Module Resolution Options */
      "baseUrl": ".",
      "paths": {
        /* Support absolute ~imports/* with a leading '/' */
        "/*": ["*"]
      },
      "moduleResolution": "node",
      "resolveJsonModule": true,
      "types": ["node", "mocha"],
      "esModuleInterop": true,
      "preserveSymlinks": true,
    },
    "exclude": [
      "./.meteor/**",
      "./packages/**"
    ]
  }

This configuration comes from the typescript template provided by Meteor. I just removed the support of JSX.

Create the file structure

We will setup a simple file structure here. For more complex projects, you should follow the guideline provided by Meteor

To initialise the file structure, run these commands

# under meteor-elm-app
mkdir client server imports/api
touch client/main.html client/main.ts client/main.css server/main.ts

Your project folder should look like this:

# under meteor-elm-app
❯ tree -I node_modules
.
├── client
│   ├── main.css
│   ├── main.html
│   └── main.ts
├── imports
│   └── api
├── package-lock.json
├── package.json
├── server
│   └── main.ts
└── tsconfig.json

4 directories, 7 files

We will update the package.json file to define the main modules in our Meteor app:

"meteor": {
    "mainModule": {
        "client": "client/main.ts",
        "server": "server/main.ts"
    }
}

At this point your package.json file should be like:

{
  "name": "meteor-elm-app",
  "private": true,
  "scripts": {
    "start": "meteor run"
  },
  "meteor": {
    "mainModule": {
      "client": "client/main.ts",
      "server": "server/main.ts"
    }
  },
  "dependencies": {
    "@babel/runtime": "^7.8.3",
    "meteor-node-stubs": "^1.0.0"
  }
}

if you need more informations about this mainModule options, you can read the content of this pull request

We now need to add some basic content to the main.html file:


  meteor-elm-app



  Elm app will be here

Checkpoint

Lets check if everything is OK before starting with Elm. Start your meteor server:

# under meteor-elm-app
meteor

Open http://localhost:3000 on your favorite browser You should see this:

Elm

Install Parcel

We will use Parcel to build our Elm application and we will use the result of this build in our Meteor application

To install Parcel, run this command

meteor npm i -D parcel

Create a Meteor package

This Meteor package will contain our Elm application and we will use this package inside the Meteor application.

We use a Package because it allows us to isolate our Elm application from the rest of the Meteor context. It is also really useful if we want to remove our Elm application or if one we don’t want to use Meteor anymore.

Let’s start by creating some folders:

mkdir -p packages/elm-app/{app,dist}

The app folder will contain the sources of our Elm application (Elm, TS and CSS files). The dist folder will contain the result of the build made by Parcel.

Because we will build with Parcel and not with Meteor, we will create a new file at the root of the meteor-elm-app called .meteorignore

#under meteor-elm-app
touch .meteorignore

Then add this line inside this new file:

/packages/elm-app/app/**/*

Because we don’t want to push the dist and the elm-stuff folders on our repository, we will add them in the .gitignore located under the folder meteor-elm-app

dist
elm-stuff

Now, let’s create a package.js file in our package:

#under meteor-elm-app/packages/elm-app
touch package.js

And add the following content in this file:

Package.describe({
    name: 'elm-app',
    version: '1.0.0',
    summary: 'elm app',
    documentation: 'add your elm app into meteor',
});

Package.onUse(function (api) {
    api.versionsFrom('1.10.2');
    api.use('modules');
    api.addFiles('dist/elm-app.css', 'client');
    api.mainModule('dist/elm-app.js', 'client');
});

Package.describe says that our package:

is called elm-app,
is in version 1.0.0

Package.onUse says that our package:

is implemented to be use with Meteor 1.10.2,
uses the modules package, so we will be able to use import {} from '',
will add the dist/elm-app.css file in the client when it will be loaded,
have a main js file for this package called dist/elm-app.js.

If you are using elm-css and if you don’t need specific css classes in your app, you can remove api.addFiles('dist/elm-app.css', 'client'); from the package.js file.

For more informations about the Package.js file, see the documentation

Create the app

We will create our Elm application under the folder packages/elm-app/app.

We need to install Elm:

meteor npm i -D elm elm-format

elm-format is not mandatory but you should use it with your IDE to format on save and to avoid problem at compile time

Then we will initialise our app with the following command:

#under meteor-elm-app/packages/elm-app/app
meteor npx elm init

Validate the creation of the elm.json file and we are good 👍.

At this step, your folder should be like this:

#under meteor-elm-app
❯ tree -I 'node_modules|.meteor' -a
.
├── .gitignore
├── .meteorignore
├── client
│   ├── main.css
│   ├── main.html
│   └── main.ts
├── imports
│   └── api
├── package-lock.json
├── package.json
├── packages
│   └── elm-app
│       ├── app
│       │   ├── elm.json
│       │   └── src
│       ├── dist
│       └── package.js
├── server
│   └── main.ts
└── tsconfig.json

9 directories, 11 files

In a first time, we will create a simple Elm application.

Create a Main.elm file inside the folder packages/elm-app/app/src with this content:

module Main exposing(main)

import Browser
import Html exposing (Html, text)

type alias Model = String

main : Program () Model msg
main =
    Browser.element
        { init = init
        , view = view
        , update = update
        , subscriptions = subscriptions
        }

init: () -> (Model, Cmd msg)
init _ =
    ("Hello from Elm app", Cmd.none)

view: Model -> Html msg
view model =
    text model

update: msg -> Model -> (Model, Cmd msg)
update _ model =
    (model, Cmd.none)

subscriptions : Model -> Sub msg
subscriptions _ =
    Sub.none

The CSS main file

In the folder meteor-elm-app/packages/elm-app/app, create an empty main.scss SCSS file (or CSS if you prefer) that we will use later to add some style in our Elm application.

NB: if you use elm-css and you don’t need a stylesheet, skip this step and remove the line api.addFiles('dist/elm-app.css', 'client'); in the package.js file

The Package mainModule

In the folder meteor-elm-app/packages/elm-app/app, create a file index.ts that will mount our Elm application and export the ports.

A simple version could be:

import './main.scss'
const { Elm } = require('./src/Main.elm')

export const init = (configuration: any) => {
    const app = Elm.Main.init(configuration)
    return app.ports
}

But because we want to Type things as much as possible, let’s create this index.ts like this:

import './main.scss'
const { Elm } = require('./src/Main.elm')

interface Flags {}

export interface Configuration {
    node: HTMLElement | null,
    flags: Flags
}

export interface Ports {}

export const init: (configuration: Configuration) => Ports = (configuration) => {
    const app = Elm.Main.init(configuration)
    return app.ports
}

With this definition, when we will need some flags or some ports, we will add the new stuff in our interface and the client will have to implement them.

If you are using CSS instead of SCSS then update the file import accordingly

Build with Parcel

Let’s create a build script in our package.json file:

"elm:build": "parcel build packages/elm-app/app/index.ts -d packages/elm-app/dist --out-file elm-app.js --no-cache",

This script will build our application in a file elm-app.js (and elm-app.css) and put it in the folder packages/elm-app/dist (the one we added in our .gitignore)

We can test our script

#under meteor-elm-app
meteor npm run elm:build

If everything is ok, you should see these lines:

Add our package to Meteor

Now that we have a package, we have to add it in our Meteor configuration.

you must have run the previous build command before adding the package because without a dist folder, you will not be able to add it.

Execute this command to add the package

#under meteor-elm-app
meteor add elm-app

You should see

Post install

To avoid to have to compile manually each time someone clone the repository, we will add a postinstall script in the package.json file:

"postinstall": "meteor npm run elm:build",

Use the Elm application in our Meteor client

Now that we have our Elm application, it is time to import it in the client side of our Meteor application

In the client/main.ts file, add the following code:

import { init } from "meteor/elm-app";
import { Meteor } from 'meteor/meteor';

Meteor.startup(() => {
    const ports = init({
        node: document.getElementById("main"),
        flags: {}
    })
})

In this code, we import the init function from the package meteor/elm-app which is the package we have just created (you can see it in the file .meteor/packages). Then we call it to mount our Elm application on the node document.getElementById("main") (the one we have created in the main.html file)

Now, if you start your meteor application by running the meteor command, on http://localhost:3000 you should see:

But…

The typing is not good

You should see that your import is underlined in red:

To fix that, we will add a declaration file:

#under meteor-elm-app
mkdir -p types/meteor
touch types/meteor/elm-app.d.ts

And add the following content

declare module 'meteor/elm-app' {
    export const init: (
        configuration: import('/packages/elm-app/app').Configuration,
    ) => import('/packages/elm-app/app').Ports;
}

Now each time we will change the definition of the type Flag or the type Port inside our Elm application, we will be sure to know if we have some stuff to fix in the Meteor client 💪.

Live Reload

Because we don’t want to build manually our Elm application each time we make a change, we will setup the live reload

We will install some packages to help us

#under meteor-elm-app
meteor npm i -D concurrently wait-on rimraf

Then we will create an new script in our package.json file:

"elm:watch": "parcel watch packages/elm-app/app/index.ts -d packages/elm-app/dist --out-file elm-app.js",

With elm:watch, parcel will rebuild our app each time we make a change in Elm, TS or SCSS files under the folder packages/elm-app/app.

And because parcel watch create a .cache folder, we will add it to the .gitignore file. The content of your .gitignore should be like this:

node_modules/
dist
elm-stuff
.cache

Now to run parcel and meteor in parallel, we will update the package.json file. We will rename the script start to meteor:run, and redefine the script start:

"meteor:run": "meteor run",
"start": "rimraf \"./packages/elm-app/dist/*\" && concurrently -n \"parcel,meteor\" -c \"magenta,green\" \"meteor npm run elm:watch\" \"wait-on ./packages/elm-app/dist/elm-app.js && meteor npm run meteor:run\"",

The script start call rimraf to clean the dist folder, then we call concurrently to run two tasks:

the parcel one, that will be log in magenta and its command is meteor npm run elm:watch
the meteor one, that will be log in green and its command is wait-on ./packages/elm-app/dist/elm-app.js && meteor npm run meteor:run (the wait-on command is use to wait the build from Parcel)

Now each time we will change our content under packages/elm-app/app, Parcel will rebuild incrementally our application and update the content under the dist folder, so Meteor will detect a change and refresh the main application.

You can now start your application by running:

#under meteor-elm-app
meteor npm start

You can make some changes in your Main.elm file and see that everything will automatically refresh in your browser.

Tailwindcss

Tailwindcss is a npm package, so we will install it like this

meteor npm i -D tailwindcss

For more informations about Tailwindcss, see the documentation

We need to initialize Tailwincss:

#under meteor-elm-app/packages/elm-app/app
meteor npx tailwindcss init

This command will generate a file called tailwind.config.js

We can now edit the file main.scss inside our app (packages/elm-app/app/main.scss) to use Tailwindcss

@tailwind base;
@tailwind components;
@tailwind utilities;

We will configure postcss to use autoprefixer and the tailwind.config.js file.

#under meteor-elm-app/packages/elm-app/app
touch postcss.config.js

And add this content to this file

const path = require("path");

module.exports = {
  plugins: [
    require("tailwindcss")(path.join(__dirname, "tailwind.config.js")),
    require("autoprefixer"),
  ],
};

We can now edit our Main.elm to add a CSS class (text-green-500) from Tailwindcss:

view: Model -> Html msg
view model =
    div [class "text-green-500"] [text model]

Then if you (re)start your server, you should see this:

Congratulations 🎉! You made your first application with Elm, Meteor and Tailwindcss 👏.

The Todos application

It is really awesome right? What? You don’t want to use Meteor just to expose static file? Hmm ok, let’s go with the Todos application

Because the goal of this post is not to learn how to code in Elm, we will start with an application I wrote for the occasion.

This application is not linked with Meteor yet, there is no ports defined. The goal is to save each Todo in MongoDB and to be able to sync two browser.

Update the Main.elm

Replace the content of the Main.elm file with this gist

We will need to add elm/svg:

#under meteor-elm-app/packages/elm-app/app
meteor npx elm install elm/svg

Then start your application

meteor npm start

You can try the application, actually we can:

Add a Todo
Switch the status of a Todo
Filter Todos by status

We will keep the filtering part in the client, but we want to:

Load Todos from MongoDB
Save new Todos in MongoDB
Switch the status and save it in MongoDB

But let’s start with the backend

Define the Todos collection and methods

Under the folder meteor-elm-app/imports/api, create a file todos.ts.

In this file we will define what is a Todo, and create the collection:

import { Mongo } from "meteor/mongo";
import { Meteor } from "meteor/meteor";

export interface Todo {
  _id?: string;
  value: string;
  status: "checked" | "unchecked";
  createdAt: Date;
}

export const TodosCollection = new Mongo.Collection("todos");

Then in the same file, we will add two Meteor methods, one to add a Todo and another to switch the status of Todo with its ID:

Meteor.methods({
  "todos.addTodo"(value: string) {
    if (value !== "") {
      TodosCollection.insert({
        value,
        status: "unchecked",
        createdAt: new Date(),
      });
    }
  },
  "todos.toggleStatus"(todoId: string) {
    const todo = TodosCollection.findOne({ _id: todoId });
    if (!todo) {
      throw new Meteor.Error("Todo not found");
    }

    const newStatus = todo.status === "checked" ? "unchecked" : "checked";

    TodosCollection.update({ _id: todoId }, { $set: { status: newStatus } });
  },
});

And at the end of the file, we will publish our collection on the server side:

if (Meteor.isServer) {
  Meteor.publish("todos", function todos() {
    return TodosCollection.find({}, { sort: { createdAt: -1 } });
  });
}

Finally we need to import this file in the file server/main.ts:

import "/imports/api/todos";

The server side in now ready.

Add ports to the Elm application

We will start by installing elm/json and NoRedInk/elm-json-decode-pipeline to decode our Todos:

#under meteor-elm-app/packages/elm-app/app
meteor npx elm install elm/json
meteor npx elm install NoRedInk/elm-json-decode-pipeline

So we will create 3 ports:

addTodo: port addTodo : String → Cmd msg
toggleStatus: port toggleStatus : String → Cmd msg
receiveTodos: port receiveTodos : (Decode.Value → msg) → Sub msg

Let’s put these port at the end of our Main.elm file:

port module Main exposing(main)

import Json.Decode as Decode
import Json.Decode.Pipeline exposing (required)

...

port addTodo : String -> Cmd msg

port toggleStatus : String -> Cmd msg

port receiveTodos : (Decode.Value -> msg) -> Sub msg

We have to change the type of the Todo.id to use a String because of the id in Mongo:

type alias Todo =
    { id : String
    , value : String
    , status : TodoStatus
    }

type Msg
    = InputChanged String
    | AddTodo
    | ToggleStatus String -- ToggleStatus now need a String not a Int
    | FilterBy Filter

We need a new variant ReceiveTodos (List Todo) for Msg to receive todos:

type Msg
    = InputChanged String
    | AddTodo
    | ToggleStatus String
    | FilterBy Filter
    | ReceiveTodos (List Todo)

We also change the update function because we will not update the todos list anymore. We will get the one we will receive from the port receiveTodos

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        InputChanged value ->
            ( { model | todo = value }, Cmd.none )

        AddTodo ->
            if String.isEmpty (String.trim model.todo) then
                ( model, Cmd.none )

            else
                ( { model | todo = "" }, addTodo model.todo )

        ToggleStatus todoId ->
            ( model, toggleStatus todoId )

        FilterBy selectedFilter ->
            ( { model | filter = selectedFilter }, Cmd.none )

        ReceiveTodos todos ->
            ( { model | todos = todos }, Cmd.none )

To finish with the Elm part, we need a subscription and some decoders to receive our Todos:

subscriptions : Model -> Sub Msg
subscriptions _ =
    receiveTodos
        (\value ->
            Decode.decodeValue decodeTodos value
                |> Result.withDefault []
                |> ReceiveTodos
        )


decodeTodo : Decode.Decoder Todo
decodeTodo =
    Decode.succeed Todo
        |> required "id" Decode.string
        |> required "value" Decode.string
        |> required "status" decodeStatus


decodeStatus : Decode.Decoder TodoStatus
decodeStatus =
    Decode.string
        |> Decode.andThen
            (\status ->
                case status of
                    "checked" ->
                        Decode.succeed Checked

                    _ ->
                        Decode.succeed Unchecked
            )


decodeTodos : Decode.Decoder (List Todo)
decodeTodos =
    Decode.list decodeTodo

If you remember, we have defined an interface Ports in the file meteor-elm-app/packages/elm-app/app/index.ts. It is time to add some definitions:

interface Todo {
  id: string;
  value: string;
  status: "checked" | "unchecked";
}

export interface Ports {
  addTodo?: {
    subscribe: (fn: (todo: string) => void) => void;
  };
  toggleStatus?: {
    subscribe: (fn: (todoId: string) => void) => void;
  };
  receiveTodos?: {
    send: (todos: Todo[]) => void;
  };
}

Link ports to Meteor.methods and subscriptions

We have some piece of code in Elm and some piece of code in the server side. Now we need to link them together, and we will do that in the file client/main.ts

We will need to import our TodosCollection and the Meteor Tracker

import { Tracker } from "meteor/tracker";
import { TodosCollection } from "/imports/api/todos";

Then we will subscribe to the output ports:

  ports.addTodo?.subscribe((todo) => {
    Meteor.call("todos.addTodo", todo, (err: Error) => {
      if (err) {
        // Maybe we should pass this error to Elm
        console.log("error", err);
        return;
      }
    });
  });

  ports.toggleStatus?.subscribe((todoId) => {
    Meteor.call("todos.toggleStatus", todoId, (err: Error) => {
      if (err) {
        // Maybe we should pass this error to Elm
        console.log("error", err);
        return;
      }
    });
  });

Here each time addTodo is called from Elm, we add a new Todo with a Meteor.call, same for the toggleStatus.

Of course we should manage the error, maybe it could be a good exercice 😁

Finally we need to send todos everytime the collection change. To do that, we use Tracker.autorun that will run the callback when necessary.

  // We use the Tracker.autorun to send todos each time the fetch result
  // changes
  Tracker.autorun(() => {
    // Maybe one day we will need to manage the subscription
    const subscription = Meteor.subscribe("todos");

    const todos = TodosCollection.find({}, { sort: { createdAt: 1 } }).fetch();

    ports.receiveTodos?.send(
      todos.map((todo) => ({
        id: todo._id || "",
        value: todo.value,
        status: todo.status,
      }))
    );
  });

Now you can restart your server, open two browsers on http://localhost:3000 and see that everything is saved and sync 👏.

Your browser does not support the video tag.

Conclusion

I hope you enjoyed this content as much as I enjoyed writing it. Three weeks ago I was sad because I could not use Meteor with Elm, so I started using it with React and Typescript 😳.

Today, I dropped React and I use Elm again and it is really pleasant.

If you liked this post, do not hesitate to share it on your favorite social networks and if you are interested by this kind of content, you can follow me on twitter @anthonny_q.

If you have any feedbacks, comments are open and you can find the sources of the project here https://github.com/anthonny/meteor-elm-todos.

Special thanks to ni-ko-o-kin, as I was very inspired by his post.

Big thanks to Yann Danthu for the review of this post 😘.

The onboarding

Anthonny Quérouil — Mon, 27 Apr 2020 00:00:00 GMT

I’m currently working on two of my side projects, ohmydeck! and ohmypages! and even though they are separated projects, they are sharing the same architecture.

ohmypages! is the new HubPress and if you used HubPress in the past, you already know the config.json that you have to configure before using your app:

{
  "meta": {
    "username": "put your username here",
    "repositoryName": "put your repository name here",
    "branch": "master"
  },
  "theme": {
    "name": "Casper"
  }
}

This kind of stuff is ok for a developer maybe, but certainly not enough for great user experience.

My goal with my tools is to provide a UX between Jekyll and Wordpress or Ghost for ohmypages! and between RevealJS with HTML and PowerPoint for ohmydeck!, so it was clear for me that I had something to do with the onboarding.

So, here is what I did

I started with a Welcome, I’m not sure about the content yet but… we’ll see 😄

The second step can be different, it depends of if you are hosted on GitHub/GitLab or on a self hosted instance.

If you are using GitHub or GitLab, I can easily calculate the provider, the url of your repository, the name of the project, if you use master or gh-pages…

So in this case, you will be redirect to the Authentication step. In the other case, you will see the step to define your Provider.

Then comes the Authentication step, since you will not be able to use the Basic Auth on GitHub, and because you can’t on GitLab too if you have 2FA activated, you will have to use a Personal token.

The password is not the one you set on GitLab or GitHub, it is a password you will have to define and it will be use to encrypt you personal token in your localStorage. So you will not have to remember your personal token to login, only this password.

The last (maybe not 🤔) step is the configuration of your repository.

Here again, two possibilities, if you use GitLab or GitHub, all the fields are in read-only because they are calculated. If not, you will have to fill the form by your own.

I think the onboarding is now really better than just a config.json file, maybe you agree, maybe not, feel free to give your feedback.

That’s all for today, in a future post, I’ll explain how I calculate all the stuff about GitHub and GitLab and how I validate datas.

4 days ago, I joined a community of Makers

Anthonny Quérouil — Sat, 25 Apr 2020 00:00:00 GMT

If you see some mistakes, feel free to open a pull request here 👍.

Motivation during this special period comes and goes, it can be hard to be at our top level over time.

That’s why this week, I looked for joining a community of makers.

My goal is to meet people having the same mindset than me, people who want to create their own business and live on their on products.

There is a lot of community of makers, some are just forums and others are more than that:

WIP Chat and Makerlog seems to be similar on some points, both are based on gamification using streaks to motivate you to ship stuff everyday.

WIP Chat does not offer free-tier, you have to spend $20 to test their product.

So I decided to use Makerlog which is free and have a business model based on donations and a premium (gold) access with more features.

Makerlog is the Home of the maker community where 4,000+ indie hackers & makers get things done together.

After my subscription on the site and a quick look around, I went on Telegram. Honestly, I really like all the stuff on Makerlog but to me, the community is the best part of the product.

There are always makers talking kindly with positivity, it is so motivating to see them going further day after day, the community is awesome, really.

There is a lot to say about Makerlog, I will certainly write another post about all the features.

In the meantime, do not hesitate to register on Makerlog and share your maker journey.

WTF?! Tu ne veux pas de ma PR ?

Anthonny Quérouil — Fri, 07 Sep 2018 00:00:00 GMT

Hier j’étais dans un jour de bonté, en soirée, je ne savais pas quoi faire de mon cul et je n’avais pas vraiment (du tout ?) envie de coder. Je suis donc allé faire un tour sur le trending GitHub et je me suis dit :

Pourquoi je ne ferais pas une PR sur un des projets avec un truc super simple, une traduction de README en français par exemple ?

Le choix du projet

Je pars sur le Trending GitHub, je filtre sur les projets JavaScript (le langage que j’utilise le plus en ce moment) et je choisis le projet Ky.

Au démarrage d’HubPress, j’avais adoré les PR avec tout ces README traduits. Du coup me voilà parti dans ma traduction, 1 heure plus tard je soumets une PR, tout fier, tout content 😀.

Et là, c’est l’accident

Ce matin je reçois une notification suite à un commentaire sur ma PR :

C’est très cordial, mais pour le coup ça m’a un peu refroidi.

Je prends un peu de recul, et finalement je me dis qu’il est tout à fait dans son droit.

Je n’ai surtout pas à me sentir frustré ou en colère.

Ce n’est pas parce que moi, je trouve cette PR intéressante, que lui doit en penser la même chose.

Ça veut dire que je ne dois plus contribuer ?

Bah non, surtout pas, au contraire faut continuer mais différemment.

La solution est simple, avant d’ouvrir cette PR, j’aurai du ouvrir une issue pour avoir son avis sur mon objectif.

Les choses auraient été claire tout suite et aucun de nous deux n’aurait perdu son temps.

Je voulais partager ça avec vous, je pense surtout aux personnes qui font leur première contribution et qui tombe dans ce genre de situation.

Continuez, partagez, donnez de vous mais surtout… commencez par ouvrir une issue !

Un Sens'it, Meteor et mon Rolling Spider décolle

Anthonny Quérouil — Mon, 31 Aug 2015 00:00:00 GMT

Comme vous l’avez peut-être lu dans mon précédent billet http://anthonnyquerouil.fr/2015/08/24/Sensit-mon-petit-objet-connecte.html, j’ai reçu récemment un Sens’it.

J’ai aussi depuis peu un Rolling-spider que je m’étais procuré dans le but de le controller avec un peu de code JS (c’est à cause de @k33g_org tout ça). L’heure est venue de mixer le tout !

L’objectif

L’objectif est plutôt simple, double cliquer sur le Sens’it et faire décoller le Rolling-spider.

Pour ce faire, voici ce qu’il nous faut :

Un Sens’it,
Un Parrot Rolling Spider,
Un framework JS permettant de controller le spider (on utilisera node-rolling-spider wrapper dans un package meteor anthonny:rolling-spider),
Un peu de Meteor pour lier le tout.

L’architecture

Le Sens’it va transmettre un message sur le réseau SIGFOX,
Les serveurs SIGFOX vont communiquer aux serveurs AXIBLE qu’un message button a été envoyé,
AXIBLE va appelé l’URL de Callback que nous aurons défini dans l’interface d’administration,
Ce callback pointera sur une application sensit.meteor.com que nous aurons déployée au préalable,
Cette dernière enregistrera une trace de l’appel dans une collection Mongo,
Notre application cliente établira une connexion DDP avec l’application sensit.meteor.com, et observera les changements effectués sur cette collection,
Au premier changement détecté, on décolle.

La remote-app : sensit.meteor.com

Définition de l’URL de callback

Dans l’interface Sens’it, nous allons spécifier une URL de callback pour les notifications de type button.

Pour rappel, ce callback est appelé via un GET et peut recevoir en query param certaines valeurs (via des variables {{my_var}}) :

device_id
device_serial_number
sensor_id
mode
notification_type
data
date

Nous pouvons donc définir l’URL suivante :

http://sensit.meteor.com/sensit-callback/button?device_id={{device_id}}&device_serial_number={{device_serial_number}}&sensor_id={{sensor_id}}&mode={{mode}}¬ification_type={{notification_type}}&data={{data}}&date={{date}}

L’application Meteor

Nous créons notre application meteor :

meteor create remote-app
cd remote-app
meteor remove autopublish insecure
rm remote-app.*
mkdir server
touch server/main.js

Pour la gestion des routes, on utilisera iron-router :

meteor add iron:router

Commençons par créer une collection notification qui aura pour but de stocker les différentes notifications reçues.

Notification = new Meteor.Collection("notification");

Il faut ensuite définir notre endpoint qui répondra à l’appel du callback.

Router.route('/sensit-callback/:type', {where: 'server'})
  .get(function () {
    if (['temperature', 'motion', 'button'].indexOf(this.params.type) < 0)
      throw new Error('Invalid type');

    var notification = _.extend({type: this.params.type}, this.params.query, {data: JSON.parse(this.params.query.data)});

    Notification.insert(notification);
    this.response.end('notification ' + notification.type + ' saved\n');
  });

Nous définissons une route /sensit-callback/:type dans laquelle :type peut prendre une des valeurs suivantes ['temperature', 'motion', 'button'].

On construit ensuite un objet notification à partir du type et des queryParam (on force la conversion en JSON du paramètre data car c’est un objet JSON stringifié).

Enfin on insère notre notification en base et on répond en confirmant l’enregistrement.

Pour que les informations présentes dans notre collection soient accessibles par notre "client", il faut les publier (au passage, on va gérer les autres types) :

Meteor.publish("remote-button", function (argument) {
  return Notification.find({type: 'button'});
});
Meteor.publish("remote-temperature", function (argument) {
  return Notification.find({type: 'temperature'});
});
Meteor.publish("remote-motion", function (argument) {
  return Notification.find({type: 'motion'});
});

Le code complet :

remote-app/server/main.js

Notification = new Meteor.Collection("notification");

Router.route('/sensit-callback/:type', {where: 'server'})
  .get(function () {
    if (['temperature', 'motion', 'button'].indexOf(this.params.type) < 0)
      throw new Error('Invalid type');

    var notification = _.extend({type: this.params.type}, this.params.query, {data: JSON.parse(this.params.query.data)});

    Notification.insert(notification);
    this.response.end('notification ' + notification.type + ' saved\n');
  });

Meteor.publish("remote-temperature", function (argument) {
  return Notification.find({type: 'temperature'});
});
Meteor.publish("remote-motion", function (argument) {
  return Notification.find({type: 'motion'});
});
Meteor.publish("remote-button", function (argument) {
  return Notification.find({type: 'button'});
});

Un peu de test

On démarre l’application :

meteor

On requête l’url :

http://localhost:3000/sensit-callback/button?device_serial_number=ABCDE¬ification_type=generic_punctual&data=%7B%22first_name%22%3A%22Anthonny%22%2C%22sensit_name%22%3A%22%22%2C%22last_name%22%3A%22Querouil%22%2C%22device_id%22%3A%22ABCDE%22%7D&device_id=1234&sensor_id=5678&date=2015-09-01T17%3A37Z&mode=6

Le service répond correctement, et notre notification est bien enregistrée :

Le déploiement

L’application sera déployée sur l’URL sensit.meteor.com :

meteor deploy sensit.meteor.com

Pour valider le bon déploiement, on peut reprendre le test effectué au préalable et le faire pointer sur notre "production" :

http://sensit.meteor.com/sensit-callback/button?device_serial_number=ABCDE¬ification_type=generic_punctual&data=%7B%22first_name%22%3A%22Anthonny%22%2C%22sensit_name%22%3A%22%22%2C%22last_name%22%3A%22Querouil%22%2C%22device_id%22%3A%22ABCDE%22%7D&device_id=1234&sensor_id=5678&date=2015-09-01T17%3A37Z&mode=6

Enfin, on vérifie que la notification est bien présente en base :

La local-app : sensit-meteor-rs

Nous avons désormais un backend qui prend en compte les différentes notifications, il nous faut maintenant une application qui tournera localement et qui réagira aux changements qui surviennent dans le backend.

L’application

meteor create local-app
cd local-app
meteor remove autopublish insecure
rm local-app.*
mkdir server
touch server/main.js

Nous allons initier une connexion DDP avec notre backend et écouter les changements qui sont faits sur la collection notification. Pour chaque notification ajoutée dans cette collection que nous appellerons RemoteNotification, nous ajouterons une copie dans notre collection locale Notification :

// Déclaration de la connexion
var remote = DDP.connect('http://sensit.meteor.com/');
var RemoteNotification = new Meteor.Collection('notification', { connection: remote });
remote.subscribe('remote-button');

// On écoute les changements effectués sur la collection en Remote
RemoteNotification.find().observe({
  added: function(notification) {
    console.log('-- remote item added --');
    // On upsert dans la collection de Notification locale
    Notification.upsert({notification._id}, {$set: notification});
  }
});

Il ne nous reste plus qu’à faire décoller le spider lorsqu’une notification est ajoutée en local :

var rollingSpider = new RollingSpider();

rollingSpider.connect(Meteor.bindEnvironment(function () {
  rollingSpider.setup(Meteor.bindEnvironment(function () {
    rollingSpider.flatTrim();
    rollingSpider.startPing();
    rollingSpider.flatTrim();

    // On observe la collection Notification, au premier ajout on decolle !
    Notification.find().observe({
      added: function (notification) {
        rollingSpider.takeOff();
        rollingSpider.flatTrim();
      }
    });
  }));
}));

Le code complet :

local-app/server/main.js

var Notification = new Meteor.Collection("notification");
var remote = DDP.connect('http://sensit.meteor.com/');
var RemoteNotification = new Meteor.Collection('notification', { connection: remote });
var isFlying = false;


RemoteNotification.find().observe({
  added: function(notification) {
    console.log('-- remote item --');
    console.log(notification);
    Notification.upsert({_id: notification._id}, {$set: notification});
  }
});
remote.subscribe('remote-button');

rollingSpider.connect(Meteor.bindEnvironment(function () {
  rollingSpider.setup(Meteor.bindEnvironment(function () {
    rollingSpider.flatTrim();
    rollingSpider.startPing();
    rollingSpider.flatTrim();

    Notification.find().observe({
      added: function (notification) {
        if (!isFlying) {
          isFlying = true;
          rollingSpider.takeOff();
          rollingSpider.flatTrim();
        }
      }
    });
  }));
}));

Décollage !

Conclusion

Ce billet est l’occasion de mettre en avant la connexion entre deux applications Meteor via le protocole DDP et de vous montrer qu’avec du javascript, on se marre bien (en tout cas, c’est vrai pour moi :) ).

Si vous avez des projets similaires, n’hésitez pas à m’en faire part, ce sera un plaisir d’échanger dessus.

Sens'it, mon petit objet connecté

Anthonny Quérouil — Mon, 24 Aug 2015 00:00:00 GMT

Il y a 5 jours, je suis tombé sur un tweet de Cédric Giorgi et je me suis empressé de répondre :

@cgiorgi carrément! :)
— Anthonny Quérouil (@anthonny_q) 19 Août 2015

Ce matin, j’ai reçu mon nouveau jouet (plutôt rapide :D )

Déballage et activation

La documentation tient sur un petit carton, mais c’est suffisant pour l’initialisation et l’utilisation de l’appareil.

L’activation du produit se fait en scannant le QR code au dos du Sens’it, on est dirigé sur la page de création de compte : un formulaire avec email et mot de passe.

Après avoir créé son compte, on peut suivre un tutoriel permettant de découvrir comment utiliser l’appareil. C’est plutôt bien fait, à chaque étape on doit manipuler le Sens’it et la page de tutoriel réagit en fonction.

Interface et configuration

Après s’être authentifié, l’accès à l’interface utilisateur du Sens’it se fait via l’url :

https://www.sensit.io/home

Mon Sens’it

Je pense que cette page présente le mode actif sur le Sens’it (je dis je pense car au moment où j’ai pris mon screen, mon Sens’it était en mode Mouvement et non Complet)

Historique

Pour le Mode affiché et le Bouton, on peut consulter l’historique :

NB: je pense qu’un bug est survenu dans l’affichage de l’historique de la température car je dois normalement avoir quelquechose (ci-dessous l’historique Température passant par le menu Tout les modes) :

Notifications

On peut aussi gérer le processus de Notification, que ce soit pour le mode ou pour le bouton :

Tout les modes

On y retrouve les mêmes fonctionnalités mais pour l’ensemble des modes, ce qui est plutôt pratique pour avoir une vue d’ensemble.

NB: dans tout les modes présents, je n’ai pas trouvé celui concernant la détection sonore.

Mon compte

Cette page présente les informations standards d’une page de compte, avec en plus la possibilité de lier ce dernier avec Facebook ou Twitter.

C’est aussi ici qu’on active l'Accès développeur qui permet notamment d’obtenir le fameux token d’accès pour l’utilisation de l’API

Reconfiguration

Pour la température, on peut changer l’intervalle de temps qui doit s’écouler entre deux remontées d’informations.

Pour la détection de mouvements, on peut jouer sur la sensibilité jusqu’à rendre le Sens’it très sensible.

NB: on ne trouve pas d’entrée pour jouer sur la sensibilité de la détection sonore (l’API fournit pourtant un service de configuration qui prend en compte cette donnée).

L’API Sens’it

Pour les développeurs, Sens’it propose une API REST.

Cette dernière est assez simple et permet les actions suivantes :

Récupération du token d’accès via login/password
Lister les devices
Consulter les informations d’un device
Changer la configuration d’un device
Récupérer les informations d’un capteur.

Petit test rapide

Je n’ai eu aucun problème pour faire mon test, j’ai activé le mode développeur, récupéré mon token et j’ai bêtement suivi la documentation fournie pour consommer l’API.

Conclusions

Je trouve le produit super sympa et le fait de me l’avoir envoyé pour un test hyper cool.

Il me reste certains points à éclaircir :

Est-ce que la détection sonore est gérée sur le modèle ? Ou est-ce prévu pour une version future ?
L’API présente une gestion multi devices mais l’interface utilisateur semble faite pour gérer un unique Sens’it. Comment on fait si on vu jouer avec deux devices ?
Existe-t-il un bugs tracker (Github, Bitbucket …) ? Peut-on contribuer ?

C’est une présentation rapide du Sens’it et je vais continuer à approfondir.

Qu’en pensez-vous, est-ce que le Sens’it vous plait ? Peut-être en avez-vous également un, faites le moi savoir ;)