Temps réel sans WebSocket

Lorsque j'ai commencé à développer sur le web en 2018, j'étais fasciné par la fonctionnalité de temps réel. Imaginez, quelqu'un change quelque chose sur une page et le changement est instantanément visible pour tout le monde. C'était comme de la magie pour moi.

J'ai ensuite appris que cette magie a un coût en termes de complexité.

À l'époque, j'apprenais Express, et construire un simple serveur web était déjà un défi.

La Première Fois ​

Plus tard, pour un projet scolaire, je devais construire un tableau de bord très simple pour gérer des appareils IoT, tout à partir de zéro. Le temps réel était une exigence pour diffuser l'état des appareils du serveur à chaque client connecté.

J'ai cherché sur internet et chaque article de blog, chaque tutoriel parlait de WebSocket. Donc, peut-être que c'était la voie à suivre. Pour ce projet, j'ai appris et utilisé Socket.IO. Le projet est sur GitHub à raspiot.

Durant la présentation, l'effet de démonstration m'a touché et rien ne fonctionnait comme prévu.

Avec un Framework ​

J'ai également essayé de construire une application web pour les étudiants de mon école afin de gérer le mentorat entre étudiants. J'étais encore débutant mais les projets sont le meilleur moyen d'apprendre, alors je me suis lancé.

J'ai utilisé Feathers, le framework API et d'application en temps réel. C'était probablement trop facile, alors j'ai décidé d'utiliser Vue pour le frontend avec Feathers-Vuex.

Je n'ai jamais vécu quelque chose d'aussi difficile pour absolument aucune valeur ajoutée à mon projet. Avec le recul, je pense que je voulais du temps réel parce que c'était à la mode (clairement, ce n'est pas une bonne raison).

C'était si complexe que je ne l'ai jamais terminé.

WebSocket est Complexe ​

Sur le web, nous utilisons un protocole appelé HTTP. La demande d'un navigateur à un serveur utilise HTTP.

WebSocket n'est pas HTTP. WebSocket est un protocole à part entière. Il est très important de le savoir car cela a des conséquences sur la façon dont nous pouvons l'utiliser.

Premièrement, WebSocket n'est pas natif sur Node.js. Nous devons utiliser une bibliothèque externe pour l'utiliser. Cela pourrait devenir un gros problème si nous devons l'intégrer dans un projet complexe.

Deuxièmement, WebSocket ne gère pas la reconnexion. Si la connexion est perdue, il n'y a pas de mécanisme intégré pour se reconnecter. Nous devons le gérer nous-mêmes. D'une certaine manière et malgré son support natif dans les navigateurs, nous devons l'utiliser avec une bibliothèque pour gérer la reconnexion. Cela commence à devenir beaucoup de complexité et de code à maintenir.

Enfin, WebSocket n'est pas HTTP, et dans votre serveur web, vous devrez gérer deux protocoles et créer un pont entre eux. La majorité du travail concerne l'authentification et l'autorisation. Cela pourrait entraîner beaucoup de logique à créer et à maintenir malgré le fait que nous pourrions déjà avoir une logique d'authentification pour HTTP. Cela implique également d'avoir une logique personnalisée côté client pour gérer l'authentification et l'autorisation. C'est parce qu'HTTP est sans état et WebSocket ne l'est pas.

La chose que j'aurais aimé entendre quand j'ai commencé avec WebSocket, c'est que toutes les données ne doivent pas être en temps réel et que des choses plus simples sont mieux que rien.

L'Autre Voie ​

La première fois que j'ai entendu parler de cette technologie, c'était lors d'un stream de Romain Lanz. Il est un mainteneur de Adonis et maîtrise le sujet.

Parfois, le temps réel peut avoir de la valeur pour un projet qui a des graphiques, des visualisations de données, des informations, des tâches asynchrones ou même un chat. Mais voyez-vous ce que toutes ces fonctionnalités ont en commun ?

Le client n'envoie pas, ou peu, d'informations. De plus, le temps de requête entre le client et le serveur n'est pas critique. Alors pourquoi aurions-nous besoin d'une communication bidirectionnelle ? Et qui ne s'intègre pas bien avec HTTP ? En 2024, je ne sais pas.

Événements Envoyés par le Serveur ​

Les Événements Envoyés par le Serveur (SSE) est une technologie qui permet à un serveur d'envoyer des événements à un client. C'est une communication unidirectionnelle du serveur vers le client.

Le client demande une ressource en utilisant l'API EventSource et le serveur répond avec un flux. C'est une connexion HTTP mais qui reste ouverte pour permettre au serveur d'envoyer des données au client. Simple, non ?

Bonus, cela gère automatiquement la reconnexion sans code supplémentaire.

Sur internet, nous pouvons souvent lire que SSE est mauvais, le client ne peut pas envoyer de données au serveur. Mais ces personnes oublient-elles comment fonctionne internet ? Oublient-elles <form> ou XMLHttpRequest ? Bien sûr que le client peut toujours envoyer des données au serveur. Aujourd'hui, le SSE n'a pas de grands inconvénients.

Un jour, nous construirons un simple chat en utilisant SSE et un formulaire pour envoyer des messages pour démontrer à quel point le web peut être simple et agréable.

En réalité, il y a une raison historique pour laquelle WebSocket était meilleur que SSE, mais cela n'est plus le cas en 2024 grâce à HTTP/2.

Pour un jeu, WebSocket pourrait être la meilleure option pour éviter la poignée de main entre le client et le serveur.

Enfin ​

Je pense que nous devrions toujours nous demander si nous avons vraiment besoin d'une communication bidirectionnelle instantanée. Si nous n'en avons pas besoin, nous devrions utiliser le SSE. C'est plus simple, c'est HTTP, et c'est puissant. Pesez toujours le pour et le contre avant de choisir, même si c'est le choix le plus populaire.

Alors, utiliserez-vous le SSE dans votre prochain projet qui nécessite du temps réel ?

Il est possible d'utiliser le SSE directement au sein de notre application puisque c'est juste du HTTP. Il est également intéressant de savoir que Mercure existe et peut être utile pour des projets plus complexes.

À bientôt dans le prochain article ! 🚀