Critique de livre et interview : Discover Meteor

Tom Coleman et Sacha Greif ont publié aujourd’hui Discover Meteor, un livre d’introduction à Meteor, un framework Web JavaScript qui simplifie le développement d’application Web temps-réel. Le livre s’appuie sur l’application “Microscope”, une version simple mais temps-réel d’un site type Hacker News/Reddit. Il s’en sert comme fil conducteur pour montrer les fonctionnalités de Meteor ainsi que son écosystème. Dans le livre, l’application Microscope est construite depuis le début jusqu’à une application fonctionnelle avec très peu de code -- une démonstration claire de la puissance du framework Meteor.

Le livre est constitué d’une trame principale et de chapitres parallèles. Les chapitres de la trame principale mènent le lecteur à travers la construction de l’application Microscope tandis que les chapitres parallèles traitent de sujets plus fondamentaux du développement avec Meteor tel que le déploiement, l’architecture pub/sub et la réactivité.

La trame principale est surtout utile pour les programmeurs qui débutent avec Meteor et qui veulent découvrir le framework étape par étape. Le mieux est alors de les suivre au fur et à mesure. Les chapitres parallèles sont intéressants pour les lecteurs qui veulent mieux comprendre les mécanismes internes du framework : que se passe-t-il à l’intérieur ? En quoi le développement avec Meteor diffère d’avec les autres frameworks comme AngularJS ? Ces chapitres sont même utiles à ceux qui ne s’intéressent pas à Meteor directement, mais souhaitent avoir une meilleure compréhension des mécaniques et des défis d’un développement temps réel.

Tous les livres devraient démarrer en convainquant le lecteur que le livre mérite d’être lu. Dans le cas de Discover Meteor, cela revient à répondre à la question : pourquoi devrais-je m’intéresser à Meteor ? Discover Meteor le fait très bien en démarrant le livre par un argument convaincant et concis qui montre le futur des applications Web à travers la perspective de Meteor :

• Faites une petite expérience mentale pour moi. Imaginez que vous ouvrez le même répertoire dans deux fenêtres différentes de votre ordinateur.
• Maintenant, cliquez dans l’une des deux et supprimez un fichier. Est-ce que le fichier disparait également dans la seconde fenêtre ?
• Vous n’avez pas réellement besoin de réaliser ces étapes pour savoir que c’est le cas. Lorsque l’on modifie quelque chose sur les fichiers de l’ordinateur, le changement est appliqué partout sans avoir besoin de rafraichir ou d’utiliser un callback. Cela se fait, tout simplement.
• Pourtant, imaginez comment le même scénario aurait fonctionné sur le Web. Par exemple, mettons que vous ayez ouvert la même interface d’administration de WordPress dans deux fenêtres différentes d’un navigateur et qu’ensuite vous ayez créé un post dans l’une d’entre elle. Contrairement à votre bureau, quel que soit le temps que vous attendrez, l’autre fenêtre ne reflétera pas le changement à moins que vous la mettiez à jour.
• Avec les années, nous nous sommes habitué à ce que les sites Web soient quelque chose avec lesquels on ne communique que brièvement et par à-coup.
• Mais Meteor fait partie d’une nouvelle vague de frameworks et technologies qui tentent de remettre en cause le statu quo en rendant le Web temps réel et réactif.

Pour en apprendre plus sur Meteor et sa communauté, InfoQ a parlé aux auteurs de Discover Meteor : Sacha Greif et Tom Coleman.

Comment vous êtes-vous impliqué dans Meteor ? Qu’est ce qui vous a plu dans ce framework ?

Sacha : J’ai d’abord abordé Meteor en travaillant sur ce qui est devenu aujourd’hui Telescope. À l’époque, je voulais construire quelque chose comme “Hacker News pour les designers”, j’ai donc cherché parmi les nouvelles applications Open Source sociales. Comme je ne trouvais aucune solution satisfaisante, j’ai décidé de prendre quelqu’un pour m’aider à construire la mienne et j’ai commencé à travailler avec un développeur Node.js.

À peu près à cette époque, j’ai entendu parler de Meteor par un ami qui connait l’équipe personnellement et qui en a parlé à mon développeur. Nous avons décidé de lui donner sa chance et nous avons passé l’application de Node.js à Meteor. Il est apparu qu’une semaine après cela, mon développeur n’a plus eu le temps et a quitté le projet. Je ne voulais pas repasser par tout le processus de trouver quelqu’un avec qui travailler, j’ai simplement décidé de prendre les choses en main et de développer l’application moi-même. Comme je n’avais pas d’expérience ni dans Node.js ni dans Meteor, j’ai considéré que je pourrais bien continuer avec Meteor. Travailler avec Meteor sur Telescope s’est avéré être très intéressant et une fois que j’avais une application fonctionnelle, j’ai open-sourcé le résultat de mon travail en espérant trouver quelqu’un dans le même esprit que moi pour m’aider sur ce projet. À vraie dire, c’est exactement comme cela que j’ai rencontré Tom.

Tom : J’étais intéressé pour essayer un framework JavaScript côté serveur depuis quelques temps quand j’ai entendu parler de Meteor. Après avoir réalisé tant de code front-end (et ainsi moins haïr JavaScript) j’en suis venu à me rendre compte qu’il y avait de vrais grands intérêts à utiliser JavaScript côté serveur à la fois pour un développeur expérimenté (réutilisation de code et maintenabilité) et également pour un débutant. J’étais très intéressé par l’idée de faciliter l’accès au développement d’application Web pour des gens ayant une expérience limitée en programmation.

Je n’avais pas réellement pensé à la perspective de temps-réel, mais quand j’ai lu la liste des fonctionnalités de base de Meteor, j’ai réalisé à quel point le temps-réel peut être simple et à quel point le futur des applications peut être extraordinaire. Ainsi, à la première occasion, j’ai créé un projet personnel avec Meteor et j’ai commencé à m’impliquer dans la communauté naissante.

Sacha est arrivé à ce moment-là, lorsque j’avais un peu de temps libre et m’a demandé de l’aider pour Telescope. J’ai pensé que le projet avait l’air génial et faire un peu d’open source m’a vraiment attiré à la fois pour aider la communauté et approfondir mes connaissances. Cela a été une grande expérience qui a mené plus loin...

Dans le livre, vous utilisez Meteorite pour installer les packages Meteor. Qu’est-ce que Meteorite exactement et quel est sa relation avec le produit Meteor, est-ce un produit de la communauté ou une initiative externe officiellement “bénie”.

Tom : Meteor a un très bon système de gestion de package qui permet d’utiliser du code côté client ou serveur tout comme d’autres ressources de façon très réutilisable. Cependant, jusqu’à il y a quelques semaines, il n’y avait pas de façon simple de créer ses propres packets et (il n’y en a toujours pas) aucun moyen prévu pour partager ses packets d’une façon open source.

Ainsi, Mike Bannister et moi avons proposé un processus raisonnablement complexe que vous aviez à suivre pour intégrer un package externe dans un wrapper pour Meteor (que nous appelions Meteorite) et créé un repository pour que les gens puissent proposer leur propre package que nous avons appelé Atmosphere. Meteorite est par définition un projet temporaire car les développeurs principaux planifient d’intégrer un jour ses fonctionnalités dans le coeur du projet. Pour le moment, je pense que cela leur permet de se concentrer sur d’autres priorités dans le sens où c’est “suffisant” pour le moment.

Il y a clairement un plan de transition pour Atmosphere et je pense qu’il continuera certainement, d’une façon ou d’une autre, chez les gens de Meteor. Je sais qu’ils font leur maximum pour faire en sorte que la transition soit aussi douce que possible.

A quoi ressemble la communauté de Meteor ? Est-elle principalement constitué de programmeurs JavaScript ou y voyez-vous également des personnes d’autres communautés (ex : Java, .Net, Python) ?

Sacha : Je pense que la communauté Meteor est plutôt variée. Il y a bien sûr de nombreux développeurs JavaScript, mais comme vous pouvez difficilement développer pour le Web sans connaître le JavaScript de toute façon, je pense que le framework est plutôt accessible même pour des développeurs habitués à Rails, Django ou d’autres frameworks Web.

Tom : Je pense que la plupart des développeurs Web ont été dans le passé des développeurs X + JavaScript, où X peut varier ; et il n’y a pas beaucoup de gens qui ont vécu dans un monde tout JavaScript. Bien sûr, des frameworks comme Meteor sont en train de changer ça, ce qui, je pense, a ses avantages.

En d’autres termes, je pense que la communauté Meteor est super et que les gens s’y entraident beaucoup. Cela a été génial de la voir grandir et de voir de plus en plus de voix s’y rejoindre et s’entraider.

Meteor semble être intimement lié à MongoDB, est-il possible et réalisable d’utiliser Meteor avec une autre base de données ?

Sacha : Pour le moment, les autres bases de données ne sont pas officiellement supportées, mais des membres de la communauté ont travaillé sur de tels packages et l’équipe de Meteor a mis le meilleur support des bases de données sur la roadmap (incluant MySQL, Redis, etc.).

Dans le chapitre sur le déploiement dans le livre, vous mentionnez que sur Heroku, il est seulement possible de fonctionner avec une seule dynamo (un unique process). Est-ce également le cas dans d’autre type de déploiements ou est-ce une limitation liée à Heroku ?

Tom : Pour que les fonctionnalités temps-réelles de Meteor fonctionnent correctement, chaque utilisateur doit rester connecté au même serveur Web pendant toute sa session. C’est une façon plutôt standard de fonctionner (appelée “sticky sessions”), mais la plateforme Heroku ne le supporte pas.

C’est par contre plutôt facile à mettre en place lorsque vous avez plus de contrôle sur vos serveurs, par exemple, il y a un processus plutôt bien décrit pour le réaliser sur AWS.

Il y a un second inconvénient avec cette approche pour le moment : il y a un délai dans la propagation de la donnée entre les serveurs web (donc si vous et moi sommes connectés à des serveurs Web différents, il y aura jusqu’à dix secondes de délai pour que j’observe les modifications que vous avez faites), mais c’est un sujet sur lequel l’équipe de développement travaille activement et qui sera résolu pour la version 1.0 de Meteor.

En dehors de votre propre application Telescope, connaissez-vous d’autres applications Meteor ?

Sacha : Vous pouvez trouver une liste de plusieurs applications Meteor et expérimentations sur madewith.meteor.com. En dehors de celles-ci, on peut trouver FriendTrumps (un jeu Facebook), Gander (un client mail), ShareWith911 (une application d’appel d’urgence), PiJS (une application qui permet de déployer facilement du code sur votre RaspberryPi), et beaucoup d’autres.

Le livre Discover Meteor atteint à la fois l’objectif d’être un bon tutoriel et une occasion de mieux comprendre la “magie” de comment fonctionne Meteor. C’est une bonne ressource pour n’importe qui souhaitant débuter avec Meteor.

À propos des Auteurs

Tom Coleman fait partie de Percolate Studio, une société de développement Web avec un focus sur la qualité et l’expérience utilisateur. Il est également le co-créateur de Meteorite et de Atmosphere package repository et il est aussi derrière de nombreux autres projets open-source avec Meteor (comme le Router).

Sacha Greif a travaillé dans différentes startups comme Hipmunk et RubyMotion en tant que product et web designer. Il est le créateur de Telescope et Sidebar (qui est basé sur Telescope), et il est aussi le fondateur de Folyo.