La technologie Server-Sent Events (SSE), sous-estimée

Les événements envoyés par le serveur (Server-Sent Events, SSE) sont sous-estimés

• La plupart des développeurs connaissent les WebSockets, mais SSE est une alternative plus simple, souvent négligée.
• SSE établit via HTTP un canal de communication unidirectionnel du serveur vers le client.
• Contrairement à la connexion bidirectionnelle des WebSockets, SSE maintient une connexion HTTP ouverte pour transmettre des mises à jour du serveur vers le client.

Pourquoi SSE est sous-estimé

• Popularité des WebSockets : les capacités de communication full-duplex des WebSockets éclipsent l’approche plus simple de SSE.
• Perception des limitations : son caractère unidirectionnel peut sembler limité, mais il suffit à de nombreux cas d’usage.

Principaux atouts de SSE

1. Simplicité de mise en œuvre

   • S’appuie sur le protocole HTTP standard, ce qui élimine la complexité de gestion des connexions WebSocket.

2. Compatibilité avec l’infrastructure

   • Fonctionne de manière fluide avec l’infrastructure HTTP existante :
     • équilibreurs de charge
     • proxys
     • pare-feu
     • serveurs HTTP standard

3. Efficacité des ressources

   • Consommation de ressources plus faible que les WebSockets :
     • nature unidirectionnelle
     • utilisation de connexions HTTP standard
     • pas besoin de maintenir en permanence des sockets

4. Reconnexion automatique

   • Prise en charge intégrée par le navigateur :
     • gestion des coupures de connexion
     • tentatives automatiques de reconnexion
     • expérience temps réel plus résiliente

5. Sémantique claire

   • Le modèle de communication unidirectionnel garantit :
     • une séparation claire des responsabilités
     • un flux de données intuitif
     • une logique applicative simplifiée

Applications pratiques

• flux d’actualités en temps réel et mises à jour sociales
• cours boursiers et données financières
• barres de progression et supervision des tâches
• diffusion en continu des logs serveur
• édition collaborative (pour les mises à jour)
• classements de jeux
• systèmes de suivi de position

Exemple d’implémentation

Côté serveur (Flask)

• La route /stream gère la connexion SSE.
• generate_random_data() génère en continu des événements formatés.
• Le type MIME text/event-stream signale le protocole SSE.
• stream_with_context maintient le contexte de l’application Flask.

Côté client (JavaScript)

• L’objet EventSource gère la connexion SSE.
• Le gestionnaire onmessage traite les événements reçus.
• onerror gère les problèmes de connexion.
• Le navigateur prend automatiquement en charge la reconnexion.

Limitations et points à considérer

1. Communication unidirectionnelle

   • possible uniquement du serveur vers le client
   • pour communiquer du client vers le serveur, une requête HTTP distincte est nécessaire

2. Prise en charge navigateur

   • bien prise en charge par les navigateurs modernes
   • un polyfill peut être nécessaire pour les anciens navigateurs

3. Format des données

   • prend principalement en charge des données textuelles
   • les données binaires nécessitent un encodage (par ex. Base64)

Bonnes pratiques

• Gestion des erreurs

  • gérer les erreurs de connexion avec eventSource.onerror.

• Gestion des connexions

  • fermer proprement la connexion une fois le traitement terminé.

• Stratégie de reconnexion

  • définir un nombre maximal de tentatives et implémenter une logique de reconnexion.

Exemple concret : l’implémentation de ChatGPT

• Les modèles de langage modernes (LLM) utilisent SSE pour fournir des réponses en streaming.
• Motifs principaux :
  • renvoyer l’en-tête content-type: text/event-stream
  • diffuser des blocs de données séparés par \r\n\r\n

Conclusion

• SSE offre une solution élégante pour la communication temps réel entre serveur et client.
• Sa simplicité, son efficacité et son intégration avec l’infrastructure existante en font un choix adapté à de nombreuses applications.
• Les WebSockets restent utiles pour la communication bidirectionnelle, mais SSE fournit une solution plus ciblée et plus pertinente pour les scénarios de streaming de données unidirectionnel.

[eususu]

J’ai effectivement utilisé SSE en implémentant OpenAI via REST.
Je compte absolument l’adopter dans les situations où une communication unidirectionnelle est nécessaire.

[galadbran]

Avec les SSE, il arrive souvent qu’ils ne soient pas bloqués par les équipements de sécurité (pare-feu applicatif web ou sécurité intelligente), mais que le streaming ligne par ligne via les caractères de saut de ligne ne fonctionne pas. En environnement on-premise, l’intermédiaire reçoit toute la réponse puis la renvoie d’un seul coup, par exemple.

[savvykang]

C’est vraiment dommage qu’OpenAPI ne prenne pas en charge SSE.

[alska1039]

C’est vraiment une excellente façon de mettre en place une communication bidirectionnelle dans un environnement NAT.

[GN⁺]

Avis Hacker News

• Mercure est un protocole ouvert basé sur SSE, utilisé comme alternative aux solutions fondées sur WebSockets. Mercure fonctionne autour d’un hub indépendant qui maintient une connexion SSE persistante avec le client et fournit une API HTTP simple utilisable par l’application serveur et le client. Mercure ajoute des fonctionnalités comme un mécanisme d’authentification basé sur JWT, l’abonnement à plusieurs sujets sur une seule connexion, l’historique des événements et l’ajustement automatique de l’état en cas de problème réseau

• Le grand inconvénient de SSE est la limite du nombre maximal de connexions lorsqu’on n’utilise pas HTTP/2. Cette limite, faible par navigateur, peut poser problème quand plusieurs onglets sont ouverts

• Dans la CLI de Doppler, SSE a été utilisé pour implémenter une fonction de redémarrage automatique. Les événements sont reçus depuis le serveur via SSE, puis les secrets les plus récents sont récupérés et injectés dans le processus de l’application. SSE a été choisi à la place de WebSockets pour éviter d’ajouter des dépendances supplémentaires à l’application Golang. Pour résoudre les problèmes de timeout HTTP, il a fallu envoyer périodiquement des événements "ping"

• Le caractère unidirectionnel de SSE peut sembler restrictif, mais il suffit dans de nombreux cas. Ses principales limites sont qu’il est réservé au texte et la limite de connexions du navigateur en HTTP/1.1. Avec HTTP/2 ou supérieur, cette limite de connexions ne pose plus problème. Si la performance est critique, on peut choisir une solution plus flexible et avec moins de surcharge en utilisant fetch et ReadableStream

• À cause de la simplicité de SSE, beaucoup de développeurs n’utilisent pas d’implémentation correcte et parsèrent les chunks de données avec des expressions régulières. Cela peut poser problème, car SSE prend en charge les commentaires dans le flux

• Data-star.dev est une bibliothèque frontend axée sur le streaming de réponses hypermédia via SSE. Elle a été développée avec Go et NATS comme technologies backend et est compatible avec toutes les implémentations SSE

• SSE n’est pas sous-estimé. Il est effectivement utilisé chez Open AI pour les complétions en streaming. Implémenter SSE dans une codebase ReactJS a été difficile, et comme Axios ne le prenait pas en charge à l’époque, il a fallu utiliser le fetch natif

• Lorsqu’SSE a été implémenté dans un projet web, le site cessait de fonctionner dès que plus de 6 onglets étaient ouverts. Firefox compte les connexions SSE dans sa limite maximale de 6 connexions par hôte, ce qui bloque les requêtes supplémentaires

• SSE est sous-estimé quand il fonctionne bien. Dans un projet en cours, il y a des difficultés liées à l’authentification et au keep-alive des tunnels. Ce n’est pas un problème du protocole, mais il est difficile de trouver une solution