Au cours de la track HTML5 de la QCon New York 2013, Matt DeBergalis a présenté Meteor, un framework open-source permettant la réalisation d'applications web temps réel, qu'il a lui-même co-fondé. Selon DeBergalis, la balance dans le choix client vs serveur a souvent évolué : du mainframe (côté serveur) au desktop (côté client), puis au web (côté serveur) et maintenant au web moderne où les capacités des clients s'élargissent et sont plus exploitées. Cependant, les outils pour créer ces applications web modernes n'ont pas suivi cette évolution selon DeBergalis. Le but de Meteor est de fournir au développeur ces outils pour créer des applications plus facilement et de manière cohérente.
On peut aujourd'hui distinguer deux parties dans les applications web modernes :
- Le côté serveur peut être fait en PHP, Java ou Ruby par exemple, en utilisant des APIs serveur spécifiques, et des outils pour compiler et gérer les dépendances du projet.
- Le côté client utilise une ou plusieurs librairies JavaScript, HTML, CSS et possède sa propre gestion de la compiltation, par exemple Google Closure Compiler.
Les deux parties communiquent en utilisant essentiellement un protocole de connexion sur mesure, généralement basé sur JSON via HTTP ou des Websockets pour envoyer des commandes : "envoie-moi telles données, enregistre cette nouvelle information, traite cet élément etc".
Meteor reconsidère cette approche et vise à rendre tous les composants temps réels. Pour cela, HTTP n'a pas été jugé adéquat. La communication (au-delà du rendu des ressources web) s'oppère plutôt via websockets en utilisant son Distributed Data protocol (DDP). Celui-ci est un protocole générique (encodé en JSON) qui supporte trois opérations de base :
- Subscribe : un client s'enregistre et dit "La collection de données X m'intéresse, envoie-moi un set de données initial, puis continue de m'envoyer tous les deltas effectués pour que je puisse garder ces données à jour."
- Publish : "La propriété X de l'entité Y a changé sa valeur à Z."
- Remote-procedure call : des appels que l'on utilise pour éxécuter une tâche distante et retourner le résultat en tolérant les erreurs.
Meteor fournit une implémentation de DDP pour le serveur et le client, écrit en JavaScript (Node.js avec Fibers sur le serveur). Toutefois, ce protocole n'est pas directement lié à son implémentation, et d'autres peuvent être écrites. D'ailleurs, une librairie pour clients .NET existe également.
Le second composant de Meteor est son moteur de vues, qui garde automatique le DOM à jour par rapport aux données, de manière similaire à ce que propose AngularJS ou les Web Components.
La troisième composante concerne le packaging. Comme Meteor décrit à la fois les parties serveurs et clientes, les outils de packaging usuels ne peuvent être utilisés. Meteor possède donc un système de packaging qui compile et gère à la fois le serveur et le client.
Meteor décide lui-même quelles parties de votre code seront éxécutées dans le navigateur ou sur le serveur. DeBergalis indique que des travaux sont en cours pour utiliser des techniques d'analyse de code statique. Le but étant d'avoir une meilleure séparation du code et que seul le code vraiment utile au client soit accessible.
L'envoi de données n'est pas le seul aspect temps réel de Meteor. Un des éléments les plus impressionnants de la démonstration était l'envoi de code à chaud au client : à chaque fois que le développeur sauve un fichier, Meteor recharge le code sur le serveur, et package puis envoie également automatiquement la nouvelle version à tous les clients. Cela permet de s'assurer que tous les clients utilisent la dernière version du code compatible avec le serveur.
Meteor a une approche full-stack intéressante pour le développement d'applications web temps réel. Pour en savoir plus sur ce framework, vous pouvez lire la documentation et essayer les exemples sur le site officiel. Il y a également un livre sur le sujet, qui a d'ailleurs fait l'objet d'une interview ici, sur InfoQ !