Meteor [1] est un framework javascript open source pour le développement d’applications Web. Son objectif premier est de faciliter et d’accélérer le développement. Nous allons, en quelques étapes, vérifier si Meteor tient cet objectif et quels sont ses points forts et faibles.

A cause de l’évolution rapide d’Internet, les applications Web doivent être de plus en plus dynamiques, performantes et distribuables. C’est dans ce contexte très exigeant qu’a été créé Meteor. Derrière ce nom assez spatial se cache un programme qui facilite le développement de sites Web à dominante JavaScript. D’après ses créateurs, Meteor permet de faire en quelques heures, ce qui aurait nécessité des semaines de développement. Dans cet article, nous allons voir ce qu’il en est et analyser comment Meteor répond aux besoins essentiels du Web moderne.

• Tout d’abord, en guise de formalités, nous verrons comment bien démarrer avec Meteor.
• Nous enchaînerons alors sur la séparation du fond et de la forme, principe primordial du Web.
• Nous nous intéresserons ensuite à la problématique classique de la gestion des données dans un modèle client/serveur.
• Enfin, nous aborderons la question de l’externalisation du logiciel Meteor, à savoir : pouvons-nous être indépendant de Meteor une fois que le site ou l’application à été créé.

Présentation de Meteor

Meteor est un programme ayant plusieurs fonctions, ce qui le rend difficile à qualifier simplement.
Il joue tout d’abord un rôle de serveur Web. En effet, c’est lui qui répond aux requêtes du navigateur et qui sert les pages.
Il joue également un rôle de framework puisqu’il fournit des mécanismes de codage qui lui sont propres. Enfin, Meteor propose aussi des lignes de commande à utiliser depuis le terminal. Celles-ci servent principalement à effectuer des actions de gestion du serveur et de gestion de projet.

Meteor est, au jour de l’écriture de cet article, en version 0.8.1. Son numéro de version atteste d’une certaine jeunesse. Pourtant, il a été créé fin 2011 . Son jeune âge lui donne un avantage sur les autres technologies poursuivant le même but, puisqu’il est né avec les contraintes du Web moderne.

Concrètement, la partie serveur de Meteor est un nœud asynchrone NodeJS [2] qui répond aux évènements générés par les clients. Ce serveur transmet les données aux différents clients en JavaScript Object Notation ( JSON [3] ).

En ce qui concerne la partie cliente, cette dernière se base sur du HTML, du JavaScript et du CSS. Enfin pour la partie base de données, Meteor propose une base de données MongoDB.

Aucune mise en forme n’est effectuée côté serveur, ce sont les clients qui génèrent le rendu du site. Cela est fait à l’aide de fragments JavaScript qui traitent et mettent en forme les données reçues.

Mais trêve de théorie, passons aux choses sérieuses et découvrons comment créer notre première application avec Meteor !

Mon premier site

Meteor est disponible sur Linux, pas encore sur Windows (pas de manière officielle en tout cas).
Sur les distributions Linux, l’installation se fait avec la commande suivante :

Une fois cela fait, il suffit d’invoquer une commande Meteor pour créer un projet :

Cette commande vient de générer la structure basique pour une application fonctionnant avec Meteor. Il ne nous reste plus qu’à lancer le serveur pour propulser votre site (presque) vide.
Pour cela, il suffit de lancer la commande suivante depuis le répertoire du projet :

Après quelques lignes de log, le serveur nous informe que le site est disponible à l’URL http://localhost:3000. Félicitations, vous venez de créer votre premier site avec Meteor !

Si vous êtes du genre à vouloir obtenir un résultat rapidement, vous allez apprécier ce qui suit. En effet, Meteor propose de mettre votre site directement sur le cloud (spatial ?) hébergé par l’équipe qui a conçu Meteor. Il vous suffit de saisir la commande suivante et votre site est lancé :

Bravo, votre application Web est déjà sur le net ! Malheureusement, elle n’est pas très intéressante pour l’instant. La partie suivante vous explique comment l’enrichir en y ajoutant un peu de contenu.

Gestion du contenu

A présent, nous voulons donc ajouter du contenu. Le mécanisme de base de Meteor pour créer du contenu est l’utilisation de fragments (déclaré par le mot clé « template »). Les éléments statiques ainsi que les fragments sont déclarés dans un fichier au format HTML. Tout ce qui concerne la partie dynamique du site Web est déclaré dans un fichier JavaScript.

Dans une application Web Meteor, nous avons donc a minima ces deux fichiers plus une feuille de style. Si vous regardez l’application que nous venons de créer, c’est en effet ce que la commande a généré. Nous allons tout d’abord nous concentrer sur les fichiers JavaScript et HTML.

Voici le code HTML de notre application :

Dans ce code, on peut remarquer les deux choses suivantes :

Les deux chaînes «  {{ > hello}} » et « {{greeting}} ».
Dans la syntaxe Meteor, « {{ > un_nom}} » permet de définir l’inclusion du contenu d’un fragment. Quant à la même syntaxe sans chevron « {{un_autre_nom}} » , elle permet d’exécuter une fonction JavaScript. Si la fonction appelée retourne un contenu, ce dernier est intégré dans la page à l’endroit de l’appel.
Dans notre page HTML, nous incluons donc le contenu du fragment « hello » dans la balise <body>.
Dans ce fragment, un appel vers la fonction « greeting » est effectué.

Observons maintenant son homologue JavaScript:

La première chose à remarquer est le test effectué au début « if(Meteor.isClient) ».

Cette condition n’est pas sans rappeler la célèbre fonction fork du langage C qui en fonction de sa valeur de retour permet de différencier le processus père du processus fils.

Ici, c’est l’appel des fonctions «  Meteor.isClient » ou «  Meteor.isServer » qui permet de savoir si le code est exécuté côté serveur ou côté client.

Si l’on regarde la suite, nous retrouvons bien la fonction « greeting » qui est appelée dans le fragment « hello ». Notez que le nom de la fonction est précédé du nom du template qui l’appelle. Nous pouvons donc avoir plusieurs fonctions de même nom, tant qu’elles ne sont pas appelées dans le même fragment.

La ligne commençant par « Template.hello.events » nous indique également que certaines actions se font sur événement provenant du fragment « hello ». Il s’agit ici d’un message affiché dans la console dans le cas où un événement « click » est lancé sur un élément de type « input ». Pour voir l’affichage de ce message, il vous faut donc lancer la console de votre navigateur.

La figure 1 nous donne un aperçu de notre page avec le message dans la console :

Figure 1 : application + console

Au travers de cet exemple, nous avons vu les principaux éléments qui permettent de rendre une page dynamique et modulaire. Malgré cela, il nous manque encore un élément fondamental pour rendre notre application Web complète : les données.

Découvrons donc désormais comment Meteor propose de gérer des données.

Base de données

Comme cité précédemment, Meteor met à votre disposition une API MongoDB (base de données de type NoSQL). Sans rentrer dans le détail ni insister sur ses points faibles, ce type de bases est moins contraignant que les bases relationnelles classiques et tient mieux la charge.

Meteor nous réserve une particularité concernant la base MongoDB : l’API est présente aussi bien sur le client que sur le serveur. Mais alors que le côté serveur bénéficie d’un accès direct à la base de données, le côté client doit se contenter d’un cache.

Le client « s’abonne » à des ensembles de données et le serveur les alimente dans le cache du client. S’il y a conflit sur la cohérence des données, c’est le serveur qui a le dernier mot.

Par défaut, Meteor simule un accès en lecture/écriture côté client en activant les packages « insecure » et « autopublish ». Cette fonctionnalité est bien pratique dans une phase de tests ou de démo mais représente une faille de sécurité en production. En effet, cela signifie que n’importe quel client peut modifier les données et les propager instantanément vers le serveur.

Il suffit toutefois d’ôter les packages pour reprendre le contrôle des données.

Une fois que le cache du client est renseigné, il reste à utiliser les données disponibles. Pour afficher des données, il faut indiquer à la page où aller chercher les éléments nécessaires à son rendu. Voici un exemple de fragment qui récupère des données dans un ensemble provenant de la base :

Cet extrait de code fait appel au fragment « color_info » pour chaque couleur dans l’ensemble de données « colors ». Si aucune couleur n’est présente, un message le signifiant est affiché. L’affichage des données provenant de la base n’est pas plus compliqué que cela.

Parce que l’on est rarement la seule personne sur le Web, une application Web est par essence multi-utilisateurs. Dès lors, la problématique de mise à jour des interfaces devient fondamentale. Si un utilisateur apporte une modification à une donnée, tous les autres utilisateurs doivent la voir de manière quasi-instantanée. Comment mettre en place ce genre de comportement ?

Avec Meteor, vous n’avez pas à vous en soucier car son moteur s’en occupe pour vous. La donnée modifiée est transmise depuis le client vers le serveur pour prise en compte dans la base. Le serveur propage ensuite cette donnée aux autres interfaces pour mise à jour dans leur cache. Cette mise à jour se fait grâce à des appels Ajax et ne provoque donc pas le rafraîchissement de la page.

Pour aller plus loin

Voici une application Web exemple que vous pouvez télécharger [ICI] pour illustrer les principes expliqués juste avant. Il s’agit d’une application Web moins minimaliste qui permet de parier sur des chevaux. Vous pouvez, depuis la console de développement, ajouter des chevaux dans la base via des commandes MongoDB.

Une fois ceux-ci ajoutés, il est possible d’en sélectionner un dans l’interface et lui ajouter ou lui retirer des paris. Il est également intéressant de faire le test en lançant deux (ou plus) navigateurs et d’observer le comportement des interfaces.

Indépendance de Meteor

Un des risques d’utiliser une application aussi jeune que Meteor concerne les doutes sur la pérennité du produit. Pour pallier à cela, Meteor propose une fonctionnalité qui permet de récupérer une version de votre application Web indépendante de Meteor. Pour ce faire, il suffit de saisir la commande suivante : Meteor bundle monApplication.tgz

Meteor produit alors une archive au format tar.gz qui peut être déployée comme une application NodeJS tout à fait valide. Vous pouvez ensuite remettre cette application en service en la déployant via une commande NodeJS analogue à la suivante : NodeJS localhost:3000 monApplication.tgz

Attention cependant, l’archive ainsi produite est compatible uniquement avec la plateforme sur laquelle elle a été générée. L’équipe de Meteor, en attendant un développement corrigeant cela, propose une solution temporaire avec le logiciel NPM.

Il faut décompresser le fichier .tgz obtenu précédemment et exécuter les commandes suivantes :

Meteor en bref

Pour résumer, le jeune âge de Meteor se fait encore ressentir dans son mécanisme d’indépendance incomplet et son indisponibilité sur toutes les plateformes.
Conséquence directe de cette jeunesse, sa communauté est à ce jour de taille assez modeste.

Malgré cela, c’est un outil qui permet de rapidement et facilement construire et déployer une application Web. On apprécie notamment sa syntaxe simple de définition de fragments ainsi que sa gestion aisée des données.

Webographie
[1] Site officiel de Meteor : www.meteor.com
[2] Site officiel de NodeJS : www.nodejs.org
[3] Site officiel de JSON : www.json.org

Il est possible de retrouver l’intégralité de cet article dans le numéro 182 du mois de Fevrier 2015 du magazine « Programmez ».