Meteor – API REST

Meteor client et serveur communiquent via un protocole appelé DDP [lien], qui fonctionne au travers d’une connexion websocket qui est maintenu tout au long de la navigation du client sur le site.

Généralement, les données sont stockées dans une base MongoDB sur le serveur. Cette base est gérée par Meteor et a des spécificités propres à Meteor (on ne peut pas greffer une base Mongo existante de but-en-blanc sans adaptation).

Pour échanger les données entre le serveur et le client, on utilise soit le système de publication / souscription [lien], soit le système de méthodes [lien].
Dans les deux cas, quand le serveur envoie un jeu de données au client, ce dernier va les stocker en local dans un genre de base MongoDB entièrement géré en javascript appelé minimongo [lien].
Cette architecture permet aux échanges d’être dynamiques et d’accélérer les temps de réponse entre les échanges. Quand le serveur met à jour une donnée, il l’envoie au client qui va l’intégrer dans sa copie des données et travailler avec. De même, si le client modifie les données qu’il possèdent en local le serveur est averti afin de faire persister ces changements dans la “vraie” base MongoDB.

Mais alors, comment cela se passe-t-il quand on doit utiliser autre chose qu’une base MongoDB côté serveur pour gérer ses données ? Et bien il faut utiliser l’API de bas niveau du système de publication [lien]. Cette API bas niveau permet de gérer soit-même le moment où le serveur indiquera au client “voici une nouvelle donnée”, “cette donnée a été modifiée” ou encore “cette donnée vient d’être supprimée”. Le client lui ne se rend pas compte de la différence car le protocole DDP est toujours utilisé pour les échanges donc il peut continuer à utiliser sa base minimongo pour stocker ses extraits de données.
Tout cela a l’air merveilleux, mais en fin de chapitre on peut lire ceci :

One point to be aware of is that if you allow the user to modify data in the “pseudo-collection” you are publishing in this fashion, you’ll want to be sure to re-publish the modifications to them via the publication, to achieve an optimistic user experience.

Oups. C’est ce qu’on veut faire nous permettre au client de modifier des informations, pas plus d’informations que ça dans la doc ? Et bien non, allons donc demander à notre cher ami Google si il peut nous aider sur ce point.

Lire la suite de « Meteor – API REST »