Quelle solution choisir pour gérer de la donnée en temps réel ? Retour d’expérience sur le protocole Mercure

Évolution des cours de bourse, commentaires et résultats d'événements sportifs, fils de discussion sur les réseaux sociaux… On ne compte plus les projets web qui impliquent un énorme flot de données à mettre à jour et à afficher en temps réel. Au-delà des problématiques d’UX et d’interfaces, cela représente pour les équipes techniques un véritable challenge qui ne peut être relevé avec le fonctionnement standard des navigateurs. S’il existe plusieurs solutions à disposition aujourd’hui capables de recevoir des mises à jour de données en direct du serveur, leur choix nécessite de prendre en compte plusieurs paramètres liés aux contraintes du projet ainsi qu’au fonctionnement et à la complexité de chaque solution technologique. 

Zoom sur les solutions de gestion de données à disposition pour les développeurs web

WebSocket

Le protocole WebSocket permet au serveur et au client (autrement dit tout au long de cet article, le navigateur de l’utilisateur) de “discuter” directement et en temps réel sans devoir attendre que l'un ou l'autre ne commence la conversation ou ne sollicite de réponse, et ce peu importe le sens de circulation des données. Une fois la connexion avec WebSocket établie, le serveur peut envoyer des messages au client et vice versa, autant que cela est nécessaire, évitant ainsi des coûts de réouverture ou de surcharge réseau. Attention, cette gestion de connexion persistante implique toutefois plus de paramétrages au niveau du serveur et du client pour surveiller et maintenir cette connexion.

Grâce à ces caractéristiques, le protocole WebSocket semble pertinent pour des plateformes où il y a des échanges fréquents, rapides, bidirectionnels et continus comme les chats, les jeux en ligne ou les outils de travail collaboratifs. 

Standardisé en 2011, il a été largement adopté par les principaux navigateurs entre 2010 et 2015. Il continue toujours à évoluer, notamment sur des sujets de sécurité ou de compatibilité, pour répondre aux besoins des applications en temps réel.

Server-Sent Events (SSE)

Le standard Server-Sent Events permet de créer un canal de communication unidirectionnel entre un serveur et un client. Une communication unidirectionnelle implique que seul le serveur puisse envoyer des flux de données, le client ne pourra qu’”écouter” sans “répondre”. 

Cette limitation par rapport au WebSocket reste toutefois un avantage car il est plus simple à mettre en œuvre. Le SSE repose sur le protocole HTTP, ce qui facilite son intégration au sein d’un écosystème technique existant : l’impact sur l’infrastructure technique pour configurer et sécuriser SSE est donc très limité puisque tout est déjà fait. La reconnexion en cas de coupure du réseau est nativement gérée, sans avoir besoin de code supplémentaire côté client pour gérer cette reconnexion. Indispensable pour une utilisation mobile !

Son utilisation est également idéale pour un système d’information ayant besoin de diffuser massivement des données en temps réel comme pour les sites affichant des cours de bourse ou des résultats / commentaires sportifs.  

Standardisé dans le cadre de HTML5 par le W3C, SSE a commencé à être supporté par les navigateurs à partir de 2011 et est aujourd'hui pris en charge par la majorité des navigateurs modernes et son adoption continue de croître.

Autres solutions minoritaires

Si WebSocket et les SSE sont les solutions les plus connues et les plus modernes sur le marché aujourd’hui, il existe toutefois quelques autres moyens pour gérer de la donnée en temps réel. 

Polling et Long Polling

Ces solutions utilisent les mécanismes natifs des navigateurs pour avoir des informations fraîches sur la mise à jour des données. Le polling va établir un contact répété avec le serveur et le long polling va ouvrir un canal de communication persistant avec lui pour optimiser les échanges avec le client. Si ce sont des solutions simples à mettre en place, elles sont génératrices de charge pour les serveurs et de temps de latence. On considère donc que c’est une solution plutôt réservée à des usages où le rafraîchissement périodique des données est suffisant et où le temps réel n'est pas strictement nécessaire, comme pour certains dashboards simples.

GraphQL Subscriptions

Développé par Facebook, GraphQL est un langage de requête pour les APIs. Il permet aux développeurs de spécifier les données dont ils ont besoin, réduisant ainsi les appels serveurs inutiles et optimisant la récupération des informations. C’est la fonctionnalité “Subscriptions” qui va assurer, en cas besoin, la partie de mise à jour en temps réel. Cette solution est imposée par le cadre GraphQL, qui lui, est complexe à implémenter. Il est donc assez rare de penser à GraphQL pour faire de la gestion de données en temps réel à proprement dit, sauf si on l’utilise déjà pour ses requêtes APIs. 

En comparaison

Retour d’expérience : le cas du site letrot.com

Chez USERADGENTS, nous avons récemment eu ces réflexions à mener, dans le cadre de la refonte complète du site letrot.com de la Société d’Encouragement à l’Elevage du Trotteur Français, une plateforme qui héberge une quantité de statistiques, de contenus et d’outils pour les parieurs de courses hippiques au Trot.

L’enjeu majeur ? Gérer le suivi d’une journée de courses impliquant plus de 300 000 événements par jour (départs, arrivées, photos finish, non-partants, changements de monte, timers…) qui arrivent en continu et qu’il faut propager sur de nombreuses pages du site en temps réel.

Après avoir analysé les outils à disposition, nous avons rapidement orienté notre choix vers Mercure, un serveur de diffusion d'événements basé sur les SSE. Sa simplicité de mise en œuvre et sa communication unidirectionnelle répondaient en effet parfaitement aux besoins du projet (une consultation temps réel d’outils / statistiques sans nécessité de réponse de la part du client). Après avoir mené un POC de faisabilité, nous avons été convaincus par l’équilibre entre la performance, la simplicité et la scalabilité de la solution.

C’est quoi Mercure et pourquoi l’avoir choisi ?

Mercure est un protocole open source qui repose sur une architecture centrée sur les SSE pour établir une communication de type "push", du serveur vers le client. Il a au départ été créé par Kévin Dunglas puis popularisé au sein de la communauté PHP/Symfony grâce à une intégration native au sein du framework. Il est toutefois compatible avec de nombreux langages et plateformes (Node, Jengo…) et son implémentation est aussi native sur les principaux frameworks front-end comme Vue.JS ou React.JS.

Plusieurs de ses caractéristiques entrevues pendant la phase de POC ont conditionné notre choix de Mercure. Notamment : 

• Une vraie simplicité d’implémentation et notamment sa compatibilité native avec le framework Symfony.

• La reconnexion en cas de perte par le client (très pratique et sans effort).
• Sa capacité à diffuser des messages et notifications à un très grand nombre de clients en même temps, et donc d’utilisateurs connectés, grâce à ses “hubs” (ou serveurs centralisés).
• Ses garanties de sécurité à travers une gestion fine des permissions via un système de jetons (JWT) qui va s'assurer que seuls les navigateurs des visiteurs du site sont autorisés à recevoir les données en temps réel.

Globalement, nous n’avons pas rencontré de complexité particulière dans l’installation et la configuration de Mercure, à part peut-être pour l’ajustement de l’application / infra avec le cache Varnish (cookie). D’un point de vue performance, le service n’a pas montré de réelle limite malgré la quantité de messages à traiter. En revanche, nous avons dû optimiser la plateforme Symfony qui diffuse les événements à Mercure puisqu’elle était incapable de traiter en temps réel cette masse d’informations. Nous avons donc souhaité muscler son jeu en implémentant le système de queuing (file d’attente) RabbitMQ pour mieux répartir les traitements à effectuer avant de générer les messages vers Mercure. 

A noter aussi que la connexion des clients au service n’a souffert d’aucun raté, même lorsque le site a enregistré des audiences records ! On dénombre par jour sur le site letrot.com en moyenne 70 000 clients abonnés au service (chiffre qui peut monter à 150 000 lors de courses importantes comme Le Prix d’Amérique Legend Race), à qui l’on va exposer ces fameux 300 000 événements journaliers.

“C’était un pari pour nous d'implémenter une solution technique sur laquelle nous n’avions que peu de recul. C’est pourquoi nous sommes passés par une phase de POC et de tests de charges complexes pour maîtriser le risque et valider la viabilité et la robustesse de la solution. Au final, les utilisateurs du site ont le droit à une expérience fluide qui leur permet de ne rien rater de leur passion.”

Mathieu Pisonero - CTO

Comment fonctionne Mercure dans notre architecture ?

Dans l'architecture choisie pour le site letrot.com, le protocole Mercure agit comme un intermédiaire entre le serveur back-end et les clients. Il est garant de la fluidité et de la réactivité de l’expérience.

Lorsqu’un utilisateur accède à la page d'une course, son navigateur va s'abonner à des événements spécifiques par le biais d’un hub Mercure (on parle de clients abonnés). Le serveur pourra alors lui envoyer des mises à jour concernant l’état de cette course, comme un changement de statut de “À venir” à “En cours” puis “Terminée”. Dès qu'un changement intervient côté serveur, par exemple lorsque ce fameux statut de course évolue, un message est envoyé au hub Mercure. Ce hub se charge ensuite de diffuser ces informations à tous les clients abonnés, garantissant ainsi que chaque utilisateur voit les informations mises à jour instantanément, sans avoir à rafraîchir sa page manuellement. De façon plus précise, on peut dire que les clients abonnés reçoivent automatiquement les nouvelles données via une connexion SSE et que le navigateur met à jour l’interface utilisateur en fonction des informations reçues.  

D’un POC à un déploiement industriel, l’implémentation du protocole Mercure dans le cadre du site letrot.com a démontré la pertinence et l’efficacité de la solution. Malgré plusieurs centaines de milliers d'événements condensés sur des courtes périodes, l’architecture SSE n’a pas montré de limite. Si c’est un succès pour nous, il ne faut pas oublier que c’est parce que la solution s’implémente sans couture au sein de notre architecture applicative Symfony. Si vous êtes confrontés à ce choix pour l’un de vos projets, il faudra le faire au prisme de vos contraintes et garder en tête que sa communication unidirectionnelle apporte quand même certaines limitations.

Besoin d’accompagnement technique sur la gestion de données pour votre site ? Contactez nos experts.