SSE est Souvent le Meilleur Choix pour les Flux en Temps Réel Unidirectionnels_

Les WebSockets sont puissants car ils supportent la communication bidirectionnelle. C'est aussi pourquoi ils sont souvent surdimensionnés. De nombreux produits n'ont pas besoin d'un canal duplex complet. Ils ont besoin d'un navigateur qui reste connecté et reçoit des mises à jour.

Pour les notifications, tableaux de bord, progrès des tâches et fils d'activité, les Événements Envoyés par le Serveur sont souvent le choix le plus épuré.

Pourquoi SSE Vieillit Bien

SSE demeure simple car il garde le modèle de transport étroit :

• requête HTTP standard
• EventSource natif du navigateur
• streaming uniquement du serveur au client
• intégration facile avec des proxys et les schémas d'authentification existants

Un point de terminaison serveur minimal ressemble à ceci :

app.get("/events", (req, res) => {
  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive",
  });
 
  res.write(`event: ready\n`);
  res.write(`data: ${JSON.stringify({ status: "ok" })}\n\n`);
});

Et le côté client est tout aussi petit :

const source = new EventSource("/events");
 
source.addEventListener("ready", (event) => {
  console.log(JSON.parse(event.data));
});

Quand les WebSockets Gagnent Encore

Les WebSockets restent le meilleur outil lorsque le navigateur et le serveur doivent tous deux communiquer fréquemment :

• interactions multijoueurs
• édition collaborative
• canaux de commande bidirectionnels
• événements clients à haute fréquence

L'erreur est de choisir les WebSockets parce que "temps réel" semble en nécessiter.

Meilleure Règle

Si le navigateur écoute principalement, commencez avec SSE. Passez aux WebSockets uniquement lorsque la communication bidirectionnelle est un vrai besoin du produit, pas juste un réflexe architectural.

Lectures Complémentaires

• MDN : Événements envoyés par le serveur
• MDN : API WebSocket