Meteor : la plateforme Web temps réel qui accroît la productivité

L'endroit où vous déciderez de placer vos fichiers va dépendre de la visibilité que vous souhaitez leur donner. Il y a donc trois possibilités : visibles par le serveur, visibles par le client ou les deux. La partie la plus sensible de votre code sera probablement accessible uniquement par le serveur, tandis que ce qui concerne l'interface sera plutôt destiné au client. Enfin, vous voudrez peut-être partager certaines bibliothèques à la fois avec le client et le serveur.

Les fichiers contenus dans les répertoires server et private sont invisibles pour le client et sont donc uniquement accessibles au serveur. À l'inverse, ce qui est contenu dans le répertoire client et public ne sera pas pris en compte sur le serveur.

Tous les fichiers se trouvant ailleurs sont visibles dans les deux cas, à l'exception de ce qui est contenu dans le répertoire tests, qui est un répertoire spécial dont le contenu ne sera pas déployé avec l'application.

Chaque fichier de votre application joue un rôle précis. Nous pouvons identifier les éléments suivants : le code JavaScript, les fragments de HTML, les mises en forme CSS et des ressources statiques (images, fichiers divers, etc.).

IV-B-1. Code JavaScript▲

IV-B-2. HTML▲

IV-B-3. CSS▲

IV-B-4. Ressources statiques▲

Meteor encourage autant que possible les développeurs à écrire leur code de manière à ce qu'il soit le moins possible sensible à l'ordre de chargement des fichiers. Il est pourtant rare de ne pas avoir à s'en soucier. Voici donc les règles à connaître pour éviter quelques maux de tête :

• les fichiers se trouvant dans des sous-répertoires sont chargés avant ceux qui se trouvent dans des répertoires parents ;
• dans un même répertoire, les fichiers sont chargés par ordre alphabétique ;
• une fois ces deux premières règles appliquées, les fichiers se trouvant dans des répertoires nommés lib sont placés avant tout le reste ;
• les fichiers correspondant au pattern main.* sont placés à la fin.

Ces règles de chargement peuvent ne pas vous convenir. Il est donc à noter que si vous tenez particulièrement à définir l'ordre de chargement exact de vos fichiers, il vous faudra constituer un package. En effet, le fichier de configuration d'un package permet non seulement de définir les dépendances avec d'autres packages, mais aussi l'ordre dans lequel doivent être chargés les fichiers qu'il contient. Pour en apprendre plus sur la création d'un package, je vous invite à consulter la documentation de Meteor.

Contrairement à ce qui se fait couramment dans nos applications Web, le serveur Meteor ne se contente pas de transmettre du HTML au client. Au lieu de ça, Meteor envoie des données « brutes » et c'est au client de les traiter. Nous allons éclaircir ce point.

La plateforme Meteor s'efforce de mettre à disposition une API uniforme côté client et serveur. C'est tout particulièrement vrai en ce qui concerne l'accès à la base de données. Ce qui veut dire qu'il est tout autant possible d'accéder à la base de données depuis le client que depuis le serveur. Je ne doute pas que cette révélation amène un certain nombre de questions. Comment les requêtes sont-elles transmises à la base de données et quid de la sécurité ?

La première chose qu'il faut savoir est que Meteor utilise une bibliothèque nommée minimongo pour simuler une base de données MongoDB côté client. Concrètement, c'est une copie de la véritable base de données qui est envoyée à chaque client. Cette copie n'est généralement pas la version intégrale de la base de données d'origine, mais contient les données que l'on souhaite rendre accessibles au client. Celui-ci peut donc effectuer des requêtes sur sa propre copie de la base de données en utilisant la même API que sur le serveur.

Pour ceux qui ne seraient pas familiarisés avec MongoDB, il s'agit d'une base de données orientée documents. Un document équivaut à un enregistrement composé de divers champs. La principale différence avec une base de données relationnelle est que ces champs ne sont pas figés, c'est pourquoi on parle de base de données schema-less (sans schéma donc). Un ensemble de documents est appelé « collection » et c'est l'équivalent d'une table dans une base de données relationnelle.

La déclaration d'une collection intitulée messages se fait de la manière suivante :

Messages = new Meteor.Collection("messages");

En général, on placera la déclaration d'une collection dans un fichier interprété sur le serveur et le client, car c'est un élément commun. Il est ensuite possible d'effectuer des requêtes sur la collection via des méthodes comme find(), findOne(), insert(), update() ou encore remove(). L'API des collections est partagée entre le client et le serveur, il est donc possible d'effectuer des requêtes de manière identique des deux côtés.

La méthode find() permet de récupérer les documents d'une collection qui correspondent au sélecteur MongoDB qui, lui, est passé en paramètre. Pour rechercher des documents selon un champ userId, on procéderait de la manière suivante :

var myMessages = Messages.find({userId: Session.get('myUserId')}).fetch();

Vous remarquerez l'usage de la méthode fetch() sur le résultat. Celle-ci permet de récupérer les résultats d'un curseur sous la forme d'un tableau, car la méthode find() renvoie en fait un curseur. De la même manière, vous pouvez utiliser la méthode count() sur un curseur pour connaître le nombre de résultats ou la méthode forEach() pour itérer sur les documents retournés :

var myMessages = Messages.find({userId: Session.get('myUserId')});
console.log(myMessages.count() + " messages found !");
myMessages.forEach(function (message) {
   console.log("Subject of message : " + message.subject);
});

En plus d'un sélecteur, la méthode find() peut prendre un certain nombre d'options dont les plus courantes sont le tri, l'offset, la limite et les champs à retourner. L'exemple suivant montre comment on récupérerait une liste de messages triés par date de création descendante, appartenant à un utilisateur connu, en limitant le nombre de résultats à 10.

var myMessages = Messages.find({userId: Session.get('myUserId')}, {sort: {crea
ted_at: -1}, limit: 10});

De manière similaire à la méthode find(), la méthode findOne() permet de récupérer un seul résultat, le premier qui correspond au sélecteur. La principale différence est qu'ici, ce n'est pas un curseur qui est renvoyé, mais directement le document qui a été trouvé :

var myMessage = Messages.findOne({userId: Session.get('myUserId')});

Pour insérer un document dans une collection, vous utilisez la méthode insert(), qui prend en paramètre l'objet à insérer. Cette fonction renvoie l'identifiant du document qui a été inséré.

var messageId = Messages.insert({subject: "un titre", content: "du texte"});

Un des avantages d'une API unique est probablement que vous n'interrompez pas la progression de votre travail quand vous développez la partie client, puisque vous n'aurez pas nécessairement à faire appel à des procédures distantes (ce qui reste toutefois possible). Vous restez concentrés sur la logique que vous implémentez et non sur les moyens d'y parvenir. Vos requêtes étant effectuées sur une copie locale de la base de données, vous aurez de plus l'impression d'une latence zéro, car les changements sont visibles immédiatement et propagés « en arrière-plan » sur le serveur. Sachez toutefois que le serveur peut tout à fait rejeter une modification et remettre votre copie locale à son état initial. Cela peut provoquer de drôles d'effets visuels si vous n'y êtes pas préparés. Toutefois, vous vous en doutez, il y a quelques précautions à prendre en matière de sécurité et de volume de données à transmettre à chaque client.

Il n'est pas souhaitable que l'intégralité de la base de données soit copiée chez chaque client. C'est la raison d'être des publications. Une publication est déclarée côté serveur et permet d'indiquer à Meteor quel sous-ensemble de vos données vous souhaitez envoyer à chaque client. Pour cela on utilise la méthode Meteor.publish() dont le premier argument est un nom arbitraire à donner à votre publication (qui sera utilisé par les souscriptions côté client) et le second une fonction qui renvoie un curseur (ou un tableau de curseurs) pour les documents pouvant être publiés.

Meteor.publish("myMessages", function () {
   return Messages.find({userId: this.userId});
});

L'expression this.userId contient l'identifiant de l'utilisateur connecté (ou null) quand utilisé au sein d'une publication. Une fonction de publication est évaluée à chaque fois qu'un client souscrit à cette publication. Cette souscription se déclare ainsi, côté client :

Meteor.subscribe("myMessages");

Le nom indiqué à la souscription doit correspondre à la publication souhaitée. Il est tout à fait possible de déclarer plusieurs publications portant sur la même collection. Un client pourra alors souscrire à l'une ou l'autre, ou même plusieurs en même temps (dans ce dernier cas, les documents seront fusionnés).

Afin que vos publications soient prises en compte, il faut prendre soin de supprimer le package autopublish. Ce package est installé par défaut. Son rôle est de publier automatiquement toutes les données à tous les clients. Cela peut être utile dans certains cas, durant la phase de développement. Il faut cependant s'assurer qu'il soit supprimé avant la mise en production de votre application (et bien avant si vous voulez tester vos publications) en utilisant la commande meteor remove :

meteor remove autopublish

Par défaut, un client peut mettre à jour la base de données sans restriction. C'est ce que rend possible le package insecure. Tout comme le package autopublish, il ne sert qu'à faciliter certaines opérations de débogage et de test pendant le développement, mais est à bannir en production.

meteor remove insecure

Une fois ce package supprimé, plus aucun client ne pourra écrire dans la base de données. Il faudra donner les droits d'insertion, de mise à jour et de suppression explicitement. Pour ce faire, Meteor met à disposition les méthodes allow() et deny() sur les objets de collection.

Le code ci-dessous montre comment autoriser un utilisateur à insérer, modifier et supprimer ses propres documents :

Messages.allow({
   insert: function (userId, doc) {
      return (userId && doc.userId === userId);
   },
   update: function (userId, doc, fields, modifier) {
      return doc.userId === userId;
   },
   remove: function (userId, doc) {
      return doc.userId === userId;
   }
});

Comme vous pouvez le voir, la méthode allow() accepte des callbacks pour chaque type d'opération d'écriture dans la base de données. Ceux-ci renvoient un booléen indiquant si oui ou non l'opération est autorisée. Les callbacks d'insertion et de suppression reçoivent en paramètre l'identifiant de l'utilisateur qui souhaite écrire dans la base de données et le document concerné. Le callback de mise à jour, lui, reçoit quatre paramètres. L'identifiant de l'utilisateur passe en premier. En second, il s'agit du document à l'état avant modification. En troisième se trouvera un tableau contenant le nom des champs que le client souhaite modifier. Enfin, le dernier paramètre est le modificateur MongoDb qui a été utilisé pour effectuer la mise à jour, par exemple {$set: {subject: « Nouveau sujet »}}.

La méthode deny() fonctionne exactement de la même manière sauf que les règles définies avec deny() ont plus de poids que celles définies avec allow(). Plus exactement, en utilisant deny() vous pourrez interdire une opération même si elle a été autorisée avec allow().

Pour qu'un code soit exécuté à chaque fois que ses dépendances changent, vous devrez le placer dans un traitement réactif. Un traitement réactif est un contexte qui contient votre code et traque ses dépendances. Lorsqu'il est notifié d'un changement, il exécute à nouveau le code dont il a la charge.

Meteor exécute le code présent dans les templates avec un traitement réactif. C'est pourquoi il est aisé de créer une interface réactive. Mais il est possible d'exécuter du code arbitraire de manière réactive côté client, à l'aide de la fonction Tracker.autorun() :

Tracker.autorun(function () {
   console.log("Currently viewing message #" + Session.get("currentMessageId"));
});

Le code ci-dessus enregistre une fonction dans un traitement réactif. Cette fonction sera exécutée à chaque fois que la valeur de Session.get(« currentMessageId ») change. Cela fonctionne, car l'objet Session est une source de données réactive.

Un traitement réactif n'est pas grand-chose sans source de données réactive. C'est cette dernière qui est responsable d'informer le traitement réactif d'un quelconque changement. Nous n'allons pas entrer dans le détail de la création d'une source de données réactive, mais sachez toutefois que le package Tracker, et plus particulièrement l'objet Tracker.Dependency, peut vous y aider. Meteor possède déjà un certain nombre de sources de données réactives comme les variables Session, les requêtes sur des collections, Meteor.user(), Meteor.userId(), etc.

À propos de l'objet Session, je souhaite y apporter une petite précision. Contrairement à ce que laisse croire son nom, il ne s'agit pas réellement d'un objet de session comme vous pourriez le penser. Voyez cet objet comme un moyen de stocker de manière globale des ensembles de clefs-valeurs. Le principal intérêt de cet objet est qu'il est réactif et il peut vous être utile dans vos templates notamment. En appelant Session.get('something') depuis un template, le template sera rafraîchi à chaque fois que vous appellerez Session.set('something', x).

Nous avons vu que certains templates contenaient des expressions de la forme {{hello}}. Il peut s'agir de deux choses. Soit le template est exécuté dans un contexte où la variable hello existe et à ce moment-là elle est affichée. Cela peut être le cas si vous étiez en train d'itérer sur une collection de documents et que le document actuel (qui sera this) contient une propriété hello. Soit il existe un helper de ce nom. Sachez d'ailleurs que les helpers ont priorité si une propriété de même nom existe dans le contexte dans lequel vous vous trouvez.

La déclaration d'un helper se fait dans un fichier JavaScript au niveau du client :

Template.hello.helpers({
    name: function () {
       return "Will";
    }
)};

Nous venons de déclarer un helper sur le template hello qui porte le nom name et qui retourne du texte. Ainsi, le template hello affichera le contenu suivant :

<div class="greeting">Hello Will!</div>

Apportons maintenant de la réactivité à tout ça. Admettons que vous stockiez le nom de l'utilisateur actuel dans l'objet Session. C'est une source de données réactive, rappelez-vous. Nous pouvons donc faire en sorte que le template hello se rafraîchisse à chaque fois que cette donnée change :

Template.hello.helpers({
    name: function () {
       return Session.get("username");
    }
)};

Puisqu'il est peu courant de changer de nom, nous allons étudier un autre cas plus probable qui est l'affichage d'une liste de messages.

Template.hello.helpers({
    messages: function () {
       return Messages.find({userId: Meteor.userId()});
    }
)};

Nous profitons ici de la réactivité apportée par le curseur retourné par la méthode find(). Ce curseur étant aussi une source de données réactive, nous sommes sûrs que notre template sera réévalué à chaque fois que les résultats de cette requête changent. Modifions maintenant notre template pour utiliser notre nouveau helper :

<template name="hello">
   <ul>
   {{#each messages}}
      <li{{subject}}</li>
   {{/each}}
   </ul>
</template>

Vous remarquerez l'utilisation d'un élément nouveau, #each qui est un helper de bloc. C'est un helper particulier qui vous permet d'itérer sur une liste d'éléments. Il en existe d'autres comme #if, et il est possible d'implémenter les vôtres. Ici, nous faisons usage de #each pour parcourir les éléments renvoyés par le helper messages. Dans notre cas ce sont des documents qui possèdent une propriété subject. Vous pouvez donc constater qu'il est simple de créer des interfaces réactives en un temps limité. Il nous reste cependant à voir comment les rendre interactives.

Il est facile d'ajouter des gestionnaires d'événement à un template. Pour cela, il suffit de passer la définition de vos événements à la fonction events() que vous appellerez sur votre template de la manière suivante :

Template.hello.events({
   'click': function (event) {
      console.log("J'ai cliqué quelque part");
   },
   'click .send': function (event) {
      console.log("J'ai cliqué sur un élément ayant la classe 'send'");
   },
   'keydown, click button': function (event) {
      console.log("Déclenché au clavier ou au clic sur un bouton");
   }
});

Le format d'un événement est simple. Vous devez spécifier le type d'événement (click, change, keydown, etc.), éventuellement associé à un sélecteur CSS pour restreindre l'événement à un élément précis. Vous pouvez séparer plusieurs événements par une virgule pour leur affecter le même gestionnaire d'événement. Le gestionnaire d'événement peut prendre en argument un objet contenant un certain nombre d'informations à propos de l'événement et des méthodes permettant d'agir sur sa propagation. Lorsque vous vous trouvez dans un gestionnaire d'événement, this contient les informations du contexte de l'élément qui l'a déclenché. Celui-ci est le contexte de données dans lequel l'élément apparaît dans le template. Cela veut dire, par exemple, que si vous itérez sur une collection de documents avec #each, et que pour chaque document vous affichez un lien, le gestionnaire d'événement prenant en charge le clic sur le lien, aura dans this le document concerné.

Meteor dispose d'un système de gestion de comptes utilisateur mis à disposition à travers ses packages standards. Ces packages ne sont pas intégrés par défaut, mais vous pouvez les ajouter à tout moment. Meteor a fait en sorte de séparer chaque aspect de la gestion de comptes dans un package différent afin que vous puissiez sélectionner ce dont vous avez réellement besoin. Le cœur du système se trouve donc dans le package accounts-base. Celui-ci est ajouté automatiquement quand vous intégrez un des gestionnaires d'authentification mis à disposition. Parmi ces gestionnaires d'authentification on trouve accounts-password qui est le système vous permettant de gérer l'authentification par mot de passe. Il en existe d'autres qui apportent l'authentification via des services tiers comme accounts-facebook, accounts-google et accounts-twitter.

Pour l'exemple, nous allons ajouter la gestion de comptes par mot de passe dans une application existante :

meteor add accounts-password

En faisant cela, le package accounts-base est ajouté implicitement puisqu'il s'agit d'une dépendance du package accounts-password. Le package accounts-base, qui est le cœur du système, ajoute la gestion de documents utilisateur dans la base de données. Il apporte également l'intégration de la propriété userId dans les publications et les méthodes Meteor que nous avons vues précédemment. Enfin, il met à disposition une API pour accéder aux documents utilisateur et gérer l'authentification.

Le package accounts-password apporte, lui, une API pour gérer très simplement l'authentification et la création d'utilisateurs avec mot de passe. Vous aurez donc accès à des fonctions comme Accounts.createUser(), Accounts.forgotPassword(), Accounts.verifyEmail() et d'autres pour implémenter l'enregistrement et la connexion d'utilisateurs.

Meteor va même jusqu'à proposer un package accounts-ui qui va mettre à disposition une interface par défaut pour les différents gestionnaires d'authentification présents dans votre application. Vous aurez alors accès à un template loginButtons que vous placerez dans votre code HTML à l'endroit où vous souhaitez voir apparaître le widget apportant tous les contrôles pour la connexion ou l'enregistrement d'utilisateurs.

Pour profiter d'une interface clef en main pour la gestion de comptes dans votre application, commencez par ajouter le package :

meteor add accounts-ui

Enfin, éditez le code HTML là où vous souhaitez voir apparaître les contrôles de login :

<body>
   <div class="myNavbar">
      <div class="title">Mon Application</div>
      <div class="login">
         {{> loginButtons}}
      </div>
   </div>
</body>

Et voilà, c'est aussi simple que ça. Vos utilisateurs peuvent ainsi créer un compte dans votre application et s'y connecter. Le comportement de ce widget est contrôlable via la fonction Accounts.ui.config(). Elle prend en paramètre un objet avec différentes clefs. Celle qui vous intéressera probablement le plus est passwordSignupFields qui vous permet de contrôler les éléments facultatifs et obligatoires lors de l'enregistrement d'un utilisateur. Pour rendre le nom d'utilisateur et l'email obligatoires vous pourrez procéder ainsi, côté client :

Accounts.ui.config({
   passwordSignupFields: 'USERNAME_AND_EMAIL'
});

Les autres valeurs de configuration possibles sont USERNAME_AND_OPTIONAL_EMAIL (nom d'utilisateur obligatoire, email facultatif), USERNAME_ONLY (uniquement un nom d'utilisateur) et EMAIL_ONLY (uniquement un email).

Une fois que votre application sera prête, vous voudrez certainement la rendre publique. Il y a plusieurs moyens de procéder, mais je ne vais parler que de l'option la plus rapide et la plus simple. L'équipe de Meteor met à disposition son infrastructure pour déployer votre application sur un sous-domaine de meteor.com. Pour cela il y a la commande meteor deploy :

meteor deploy mon-application.meteor.com

Il faut évidemment que le sous-domaine ne soit pas déjà utilisé. La première fois que vous déployez une application, on vous demandera d'entrer une adresse email pour vous créer un compte développeur. On vous enverra alors un email pour activer votre compte, choisir un identifiant et un mot de passe. Une fois ceci fait, vous pourrez utiliser la commande meteor login pour vous connecter avec votre compte développeur. Lorsque vous êtes connecté, vous pouvez déployer votre application avec meteor deploy.

Il vous est possible d'autoriser d'autres développeurs à déployer votre application et accéder à ses données avec la commande meteor authorized. La commande suivante liste les développeurs autorisés pour votre application :

meteor authorized mon-application.meteor.com

Vous pouvez ajouter un nouvel utilisateur de la manière suivante :

meteor authorized mon-application.meteor.com --add pierre

De la même manière vous pouvez utiliser meteor authorized <application> --remove <username> pour supprimer l'autorisation d'un utilisateur. Sachez que le fait d'autoriser un utilisateur lui confère les mêmes droits que vous. Il pourra ainsi ajouter et supprimer d'autres utilisateurs.

Pour finir, la commande meteor list-sites vous permet de lister toutes les applications déployées sur les infrastructures Meteor avec votre compte.