Express + React + Flux

Avant-propos

Nous avons besoin de mettre en place une stack de développement pérenne qui permette de réaliser des sites dynamiques, fluides et rapides. Deux pré-requis étaient de pouvoir utiliser des API REST en tant que fournisseurs de données et d’utiliser React [lien] en tant que moteur de vue (+ utiliser l’architecture de Flux [lien] et son flux de données unidirectionnel).

La question a alors été de choisir le langage de programmation qui serait utilisé pour la partie back-office. Ce choix a été porté sur NodeJS et a donc amené au second questionnement : quel framework utiliser ?

Étant le seul développeur, mon choix s’est porté sur Express [lien] qui est un des frameworks NodeJS les plus connus. Il existe tout un tas de modules prêts à l’emploi qui offres de nouvelles fonctionnalités à ses capacités de base.

Pour ce qui est de la partie front, comme indiqué précédemment, il faut utiliser React. Lire la suite de « Express + React + Flux »

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 »

AWS – Retours de veille

Avant-propos

Cet article explique les tests effectués pour mettre en place une API REST en utilisant plusieurs services Amazon. Le but n’est pas de donner une solution clef en main sur quoi utiliser mais de défricher un peu les différents services existants et le rôle qu’ils jouent dans cette architecture.

Tout ce qui est dit ici ne reflète que mes recherches personnelles et ne saurait être pris pour argent comptant car je ne saurais dire si c’est ce sont les meilleurs utilisations que je fais et si elles sont fiables.

Je vais donc dans un premier temps expliquer grossièrement à quoi sert chaque service, puis j’expliquerais l’architecture que j’ai essayé de mettre en place et enfin je terminerais par exposer mes recommandations actuelles pour mettre en place une API avec les besoins qu’avait mon entreprise à ce moment.

Lire la suite de « AWS – Retours de veille »