So what is Meteor?

Il y a quelques jours, un (enième) framework javascript faisait son lancement : Meteor. Un très bon lancement d’ailleurs, avec un site agréable, 3 petites applications d’exemple, presentées avec des screencasts clairs. Cette sortie est remarquée et se retrouve rapidement commentée sur Hacker News, Twitter et Quora. Car Meteor est un framework de développement d’application web full stack en javascript qui entend bien révolutionner notre façon de coder.


Pourquoi autant d’attention pour un framework vieux de quelques jours ? Parce qu’il y a quelques idées très intéressantes à étudier! Le site annonce la couleur de suite : développer rapidement une application web de qualité dont l’une des qualités, et pas des moindres, est de pouvoir faire du temps réel. Et il faut reconnaitre que leurs démos sont enthousiasmantes : il y a longtemps que je ne m’étais pas dit ‘il faut que j’essaye ce truc!’ en regardant un framework web! Pour avoir fait un petit essai d’appli, c’est simple à mettre en oeuvre, et en une heure j’avais une petite démo qui tournait en ligne (meteor propose son service d’hébergement). L’une des fonctions extrêmement agréable en code est l’auto refresh du navigateur. Play! mettait déjà en avant son cycle de développement rapide, à la portée d’un refresh manuel d’une seconde (enfin ca c’était avant la version 2…). Ici même plus besoin de cette étape, votre navigateur est automatiquement notifié d’un changement et les affiche à l’écran. En dual-screen, c’est un bonheur à coder! Faisons un petit tour sous le capot maintenant.


Real time

Plutot que d’envoyer du html a votre client, Meteor propose d’envoyer seulement les données et de laisser le client décider de la façon dont elles doivent être affichées. La où Meteor donne son effet “wahou”, c’est par sa gestion native du temps réel. L’objet affiché dans votre navigateur a été modifié par un autre utilisateur ? No problem, Meteor va informer tous les clients de cette modification, et vous allez voir votre affichage se modifier en conséquence! C’est vraiment impressionnant d’obtenir un tel résultat sans rien coder, et rien que pour ça, prenez 5 minutes et essayez. D’autres outils proposent également de vous aider à bâtir des applications avec temps réels dont socketstream qui est très bon et s’appuie sur socket.io (le lead développeur de socketstream explique la différence de philosophie, socketstream etant beaucoup plus léger et prévu pour s’intégrer en complément d’autres frameworks). Ici Meteor a fait le choix d’utiliser SockJS, une librairie un peu équivalente. Mais pour l’instant rien ne passe par les websockets, tous les transferts de data sont par requête xhr (dans le code source il est indiqué que c’est par soucis de compatibilité avec les différentes navigateurs, mais c’est évidement modifiable). Tout se passe par un système de publish/suscribe que l’on retrouve de plus en plus et qui est très intéressant (vos clients s’abonnent à des événements qui les intéressent et réagissent en conséquence).


Auto refresh

Lorsque vous êtes en train de développer, la sauvegarde d’un fichier sur votre poste va automatiquement rafraichir le navigateur avec vos modifications. Comme je le disais en introduction, c’est un vrai bonheur et c’est quelque que l’on voit apparaître un peu partout. Ce principe de modification à chaud est aussi disponible en production : Meteor annonce qu’une nouvelle version de votre application peut être déployée de façon transparente pour vos utilisateurs (bon ça je pense que personne n’a vraiment testé…).


Node.js as runtime

Node.js gagne en maturité et devient un runtime vraiment intéressant pour bâtir des applications (pas forcément des webapps d’ailleurs). On trouve déjà des frameworks webs par poignées, l’un de mes préférés étant Express. Celui ci est différent à bien des égards par rapport à ce qu’il existe déjà, par son aspect full-stack et temps réel. Mais un point a dérangé pas mal de monde, une phrase de la doc indiquant : “In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node”. L’encapsulation de Node est donc différente de ce à quoi nous sommes habitués dans la majeure partie des cas. Mais tout ça est transparent pour le développeur, et l’équipe derrière a l’air d’avoir une certaine “street cred” (notamment les développeurs d’Etherpad, un Google Docs avant l’heure, d’ailleurs racheté par Google par la suite), donc leur choix n’est peut être pas aussi absurde qu’il peut en avoir l’air a première vue. Cette gestion différente de Node se fait grâce à la librairie node-fibers entre autre. En tout cas, même si vous n’avez jamais fait de Node.js, aucun problème pour se lancer avec Meteor, tout est transparent. Nodejs est d’ailleurs le seul prérequis pour déployer une application Meteor.


Partage du code client et serveur

Meteor est un framework full stack qui donne les outils nécessaires pour faire votre application depuis le templating client à la persistance en base de données. Mais de plus pour Meteor, vos objets javascripts clients sont les mêmes que les objets javascripts serveurs. On dénombre quelques frameworks javascripts qui ont la même idée, comme par exemple Tower.js, voire même des choses assez proches de Meteor comme Derby (beaucoup de features identiques sont présentes, au point que l’équipe de Derby a fait un billet pour expliquer leurs différences). Plus que les objets, se sont même les fonctions qui peuvent s’exécuter indifféremment côté client ou côté serveur!

Le code est à tel point partagé que par défaut, vous écrivez les deux parties dans le même fichier (chaque partie étant quand même identifiée, mais on peut partager des fonctions entre les deux). Vous pouvez également scinder ce fichier, la convention étant de créer un dossier ‘client’ et un dossier ‘serveur’ qui contiennent vos fichiers.


Base de données

Par défaut, c’est une instance MongoDB qui est lancée pour la persistence. MongoDB est une base NoSQL, orientée document, dont l’API est en javascript. Cette API est d’ailleurs disponible aussi bien dans la partie serveur que dans la partie cliente! Hein? Oui, en fait, Meteor va répliquer la base de données dans le navigateur, pour que vous puissiez manipuler un ensemble valide de données directement depuis le client (on imagine bien que ce système a des limites, mais n’est pas trop détaillé à ma connaissance).


Côté client

Le système de templating retenu est Handlebars par défaut, mais il est à priori possible de choisir son préféré. Pour le reste, le comportement ressemble à beaucoup d’autres frameworks à la Backbone : vous définissez à quels ‘events’ vont réagir vos objets et la façon dont ils vont réagir. Pour manipuler le DOM vous pouvez utiliser votre bibliothèque favorite (en interne Meteor utilise JQuery). Ce qui est intéressant c’est qu’une action côté client n’attend pas forcément la réponse du serveur : elle va effectuer son action immédiatement (en simulant la requête, puisque votre base de code fonctionne aussi bien côté client que côté serveur). Quand le serveur renvoie sa réponse, le client compare les résultats et se met à jour en conséquence. Cette fonctionnalité s’appelle la ‘compensation de latence’ et permet également de faire fonctionner Meteor en offline : si votre serveur est indisponible, le client va effectuer tous les traitements localement, donnant l’impression que tout fonctionne normalement. Lorsque la connection est rétablie, les requêtes en attente sont jouées sur le serveur et le client se met à jour. Ce mécanisme est détaillé par l’un des développeurs sur stack overflow.

Le protocole de communication client serveur est de leur cru et baptisé DDP (ce n’est donc pas du REST par exemple, bien que les développeurs indiquent qu’il est simple d’adapter DDP pour en faire du REST, ou le connecter à d’autres protocoles, mais cela manque un peu de doc là encore).


Packaging

Meteor vient avec son propre système de gestion de dépendances et de packaging. C’est bien fait et efficace mais cela ne s’appuie pas sur NPM qui est pourtant devenu le standard de facto de la communauté Node, et qui s’avère très très pratique. Un choix un peu discutable donc. Un certain nombre de packages sont déjà disponibles, dont backbone ou less par exemple. Côté déploiement, c’est vraiment efficace : un simple “meteor deploy” pousse votre application sur le service de hosting maison de Meteor (sur une url etant par défaut lenomdemonappli.meteor.com). Il est possible de sécuriser le déploiement de l’application avec un mot de passe (option -P).

Sécurité

L’un des points non traités pour l’instant, et non des moindres, est la partie sécurité/authentification. Pour cette version, on ne peut tout simplement rien faire dans ce domaine, donc une application mise en ligne peut voir sa base de données vidée en quelques secondes (l’API de la base étant exposée côté client, une petite requête dans la console javascript et c’est plié).

Licence

Un dernier mot sur la licence : Meteor est en GPL, licence virale par excellence. Donc tant que vous faites vous aussi du GPL et que vous redistribuez votre code pas de soucis, sinon vous êtes encouragés à contacter l’équipe de Meteor (entendez, éventuellement payer) pour une utilisation commerciale. Ca n’est pas fondamentalement gênant, et on comprend bien qu’ils veulent gagner leur vie. Bien d’autres outils connus utilisent cette double licence (MySQL par exemple), mais c’est finalement assez peu courants dans les projets Javascript, qui ont habituellement des licences plus permissives. La question qui se pose est : est ce que cela va limiter l’adoption et les contributions à Meteor? Cet article vous expliquera tout ça mieux que moi si le sujet des licences vous intéresse.

Edit : depuis l’écriture de ce post, la licence est passée en MIT. Comme quoi, le pouvoir de la communauté…


J’espère que cet article vous aura fait partager mon enthousiasme pour Meteor, bien que j’explique également les quelques choix qui font débat. Le meilleur moyen de vous faire votre avis est vraiment de regarder les quelques screencasts disponibles. Il y a d’excellentes idées dans cet outil, et nous allons voir de plus en plus de frameworks nous offrir ce genre de fonctionnalités pour faire des applications web bien différentes de ce que nous faisons actuellement.

À propos de Cédric Exbrayat

Cédric Exbrayat, développeur et fondateur Ninja Squad, se réunit avec ses semblables régulièrement que ce soit au Lyon JUG ou à Mix-it, dont il est le fondateur. Java et JS for food and fun.

Publié le 23/04/2012, dans Tools, et tagué , . Bookmarquez ce permalien. 5 Commentaires.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :