La programmation asynchrone est de plus en plus souvent présente dans nos développements. Les microservices multiplient le nombre de composants présents dans notre infrastructure et la communication synchrone pour réaliser un traitement n’est plus une solution viable. Trop d’adhérence entre les services ; en microservices, on part du principe qu’il y a forcément un élément qui est down.
La communication back-end utilise de plus en plus des modèles asynchrones (Kafka, AMQP, JMS, etc…). Nos services “s’isolent” pour mieux fonctionner ensemble par des notifications.
Comment nos services peuvent notifier la fin d’un traitement ou l’avancement du traitement vers le front pour qu’il puisse réagir.
Les Méthodes
Client pulling
Méthode bête côté front, une requête tous les 5 secondes pour dire “Dans quel état est mon traitement ?” et le service doit répondre à chaque fois. Pour que le service puisse réponde correctement, il doit connaître l’ensemble du traitement pour interroger la base de données ou le bon service afin de collecter les bonnes informations, que le front peut déjà avoir en sa possession. Du traitement pas toujours simple dans un système fortement distribué, où plusieurs tâches peuvent être réalisées en concurrence.
Web Socket
Le protocole Web Socket existe, elle permet de faire une communication entre le front et le back en temps réel dans les deux directions. Ça implique d’implémenter un autre protocole, qui n’est pas toujours supporté par les proxy et pare-feu.
Server-Sent Events
La technique Server-Sent Events (SSE) pour établir une connexion du back vers le front. Le front s’abonne au back, et le back émet des données dans la connexion.
- Simple et efficient, basé sur une communication unidirectionnelle, l’architecture se simplifie par rapport au Web Socket.
- Basé sur HTTP, le protocole HTTP est très bien supporté sur l’ensemble des navigateurs et s’intègre mieux avec l’infrastructure existante telle que HTTP/2, les proxys et les pare-feu.
- Reconnection automatique, SSE est en capacité de se reconnecter automatiquement si la connexion est interrompue.
- Événements typés, il est possible de typer les événements pour mieux les identifier dans une application gérant plusieurs événements.
Limitation de SSE:
- Bien que SSE est bien supporté par tous les navigateurs modernes. L’API EventSource est normalisée dans le cadre de HTML5 sortie en 2014, mis en draft en 2011, cette API peut encore être considérée comme jeune.
- SSE est optimisé pour du texte ; ce n’est pas possible d’envoyer du binaire.
- Si on utilise HTTP/1, il y a une limite technique : le nombre de connexions ouvertes par navigateur à 6 pour un même domaine. Ce qui implique qu’on peut bloquer l’ensemble d’une page web, si on a plusieurs onglets d’ouvert. Pour contourner cela, on cherchera à mettre en place un “shared worker”.
- Si l’application a beaucoup d’utilisateurs simultanés, le serveur doit être en capacité de maintenir un nombre important de connexions HTTP.
Conclusion
L’utilisation du Server-Sent Events (SSE) permet d’avoir un approche au temps réel plus simple que l’utilisation d’un simple client pulling aura du mal à répondre sans créer une surcharge importante sur l’infrastructure. Ça mise en place peut-être élégante, il faudra bien prendre en compte toutes les contraintes lors de la reconnexion du client ou lorsqu’ notre environnement contient plusieurs serveurs. SSE offre une mise en place plus simple et moins coûteuse que d’utiliser le protocole Web Socket.
Aller plus loin
Pour mieux comprendre, vous pouvez trouver un POC sur la Mise en place de Server-Sent Events.
Sources: