Relier Lemmid Store aux cuisines

Résumé

Pour l'appli de commande de repas que je construis, j'avais besoin de concevoir un moyen fiable de la relier à des systèmes externes. Ces systèmes échappent à mon contrôle direct : caisses enregistreuses, systèmes de gestion de cuisine et imprimantes de tickets, tous différents. Lis la suite pour en savoir plus sur la conception face à l'inconnu et à l'instable.

Texte intégral

L'appli de commande de repas

L'appli que je construis s'appelle Lemmid Store. C'est une appli conviviale qui permet de passer (et de payer) des commandes de plats à emporter. Tu trouveras tous les articles sur Lemmid Store ici.

Systèmes externes

Le besoin de se connecter à des systèmes externes vient de l'envie d'intégrer l'appli de commande aux processus métier du service de livraison de repas. Pense à des choses comme :

• collecter les données de commande dans des registres administratifs (par ex. la comptabilité)
• transmettre les commandes aux cuisines, où les repas sont préparés et emballés
• donner un accès facile aux informations d'itinéraire, pour savoir où livrer
• planifier les commandes destinées à des livraisons ultérieures

Les défis de la connexion à des systèmes externes

Tu ne t'en rends peut-être pas compte, mais se connecter à des systèmes externes peut être délicat. Si tu imagines l'appli de commande comme une sorte de « moteur » (comme dans ta voiture), tu veux en gros intégrer ce moteur à des pièces externes. Comme tu peux l'imaginer, toutes les pièces ne se logent pas aussi bien sous le capot. Pour compliquer les choses : tu ne sais pas vraiment à quel point ces pièces externes sont fiables. Tu dois concevoir ton intégration de façon à pouvoir brancher facilement différentes pièces externes, et à ce que les performances ne dépendent pas de leur fiabilité.

Comme avec un moteur à combustion, il faut penser à l'ajustement et à la fiabilité quand tu intègres ton logiciel à des systèmes externes. Tu ne peux pas supposer qu'un logiciel externe :

• s'adapte parfaitement
• est toujours cohérent
• est toujours disponible / présent
• est digne de confiance

Pour répondre à cette vision plutôt sombre des connexions externes, j'ai pensé qu'il valait mieux que le serveur principal de mon appli de commande délègue la connexion aux systèmes externes à un « serveur connecteur » conçu pour cela. Ce serveur connecteur se connecte alors de façon indépendante au système externe. Ainsi, le serveur principal ne communique qu'avec des pièces et des systèmes « de première partie », ce qui limite les risques d'incompatibilité et de pannes éventuelles.

En pratique, le « serveur connecteur » est donc une autre machine, avec sa propre pile logicielle. Cette séparation présente quelques avantages importants :

• sécurité : le serveur connecteur ne conserve pas l'historique complet des commandes, seules celles à transmettre à un système externe restent temporairement en mémoire. Un éventuel problème de sécurité dans un système externe n'exposera qu'un minimum de données.
• s'adapte à tout : le serveur connecteur peut gérer de nombreux protocoles et manières de se connecter à des systèmes externes. Ajouter une connexion revient à faire « apprendre une nouvelle langue » au serveur. Comme il est déjà polyglotte, ajouter un nouveau dialecte ou une nouvelle langue est souvent facile. Se connecter à différentes API externes est plus simple quand tu as tous les éléments pour (re)structurer les données.
• absorber l'instabilité : un simple mécanisme de file d'attente dans le serveur connecteur lui permet de gérer élégamment les pannes et les problèmes de connexion externe. En journalisant et en mettant en file d'attente par service externe, on peut limiter l'impact sur les autres parties et connexions quand un service tombe.

Conclusion

Aussi tentant que ce soit de greffer simplement de nouvelles pièces à la mode sur ton appli, tu dois réfléchir soigneusement à ta configuration pour qu'elle reste fiable.

Concevoir un logiciel serveur qui se connecte à des API externes est un vrai défi. Il faut espérer le meilleur, mais concevoir pour le pire !