Guym code

Server Side Event en .net 10

 
  • 08 Aug, 2025

Server-Sent Events (SSE)

Server-Sent Events (SSE) permettent à un serveur d’envoyer des mises à jour en temps réel à un navigateur via une connexion HTTP unidirectionnelle. Contrairement à WebSockets, SSE est plus simple et utilise le protocole HTTP standard.

Cas d’usage courants des Server-Sent Events (SSE) dans les applications web :

  1. Mises à jour de tableaux de bord
    Actualisation automatique des données affichées (statistiques, graphiques, monitoring).

  2. Flux d’actualités ou de réseaux sociaux
    Affichage en direct des nouveaux posts, commentaires ou tweets.

  3. Suivi de progression
    Transmission de l’état d’avancement d’un traitement long (upload, génération de rapport).

  4. Monitoring système
    Surveillance en temps réel de serveurs, capteurs ou applications (logs, métriques).

SSE est particulièrement adapté pour les scénarios où le serveur doit pousser des informations vers le client dès qu’elles sont disponibles.

Fonctionnement SSE

  • Connexion unidirectionnelle : Le client (navigateur) ouvre une connexion HTTP vers le serveur, qui reste ouverte.
  • Format des données : Le serveur envoie des événements au format texte (text/event-stream).
  • Réception côté client : Le client utilise l’API JavaScript EventSource pour recevoir les événements.

Implémentation SSE avec ASP.NET Core (.NET 10)

Exposer un endpoint SSE dans ASP.NET Core :

app.MapGet("/sse", async context =>
{
    context.Response.Headers.Add("Content-Type", "text/event-stream");
    for (int i = 0; i < 10; i++)
    {
        await context.Response.WriteAsync($"data: Message {i} à {DateTime.Now}\n\n");
        await context.Response.Body.FlushAsync();
        await Task.Delay(1000); // Envoie toutes les secondes
    }
});
  • Le header Content-Type doit être text/event-stream.
  • Chaque message commence par data: et se termine par deux sauts de ligne.
  • Utilisez FlushAsync() pour pousser les données immédiatement.

SSE fasse aux autres méthodes

Voici les principaux avantages et inconvénients des Server-Sent Events (SSE) par rapport à d’autres méthodes de communication en temps réel (websocket signalR):

Avantages des SSE

  • Simplicité d’implémentation
    SSE utilise HTTP standard, ce qui facilite la configuration côté serveur et client.

  • Unidirectionnel serveur → client
    Idéal pour les notifications, mises à jour ou flux de données où seul le serveur envoie des informations.

  • Gestion automatique de la reconnexion
    L’API EventSource côté client gère la reconnexion en cas de perte de connexion.

  • Compatibilité avec les proxies et firewalls
    SSE fonctionne bien avec la plupart des infrastructures réseau, car il repose sur HTTP.

  • Faible consommation de ressources
    Moins gourmand en ressources que les WebSockets pour des flux unidirectionnels.

Inconvénients des SSE

  • Unidirectionnel uniquement
    Impossible d’envoyer des données du client vers le serveur via la même connexion (contrairement à WebSockets).

  • Support limité côté navigateur
    Certains navigateurs mobiles ou anciens ne prennent pas en charge EventSource.

  • Limité à HTTP/1.x
    SSE ne fonctionne pas nativement avec HTTP/2 ou HTTP/3.

  • Scalabilité
    Maintenir de nombreuses connexions ouvertes peut être difficile à grande échelle.

Comparaison avec d’autres méthodes

  • WebSockets
    • Bidirectionnel (client ↔ serveur)
    • Plus adapté aux applications interactives (chat, jeux)
    • Plus complexe à mettre en œuvre et à sécuriser
  • Long Polling
    • Simule le temps réel en interrogeant le serveur à intervalles réguliers
    • Moins efficace, plus de latence et de consommation réseau

En conclusion

Le SSE à travers un endpoint .NET convient aux cas simples localisés : Comme il se base sur un Endpoint, il n’est pas possible d’accéder directement et facilement à cet endpoint depuis un service quelconque pour envoyer une notification comme on le ferait avec l’injection de SignalR. Il faudrait également retrouver l’instance d’endpoint correspondant à l’utilisateur à notifier. Si en plus l’application fait du scaling horizontal, il faudrait un mécanisme de communication inter instances pour que le message remonte à la bonne instance du bon endpoint.

Le SSE .NET est parfait pour implémenter simplement des flux de retour asynchrone :

  • une barre de progression sur un calcul un peu long.
  • un tableau de bord avec des données qui arrivent en continu Dans ces exemples, le navigateur s’abonne à l’endpoint sur une instance et affiche les données qui arrivent en continu pour cette action de cet utilisateur.

Dans les autres cas préférer SignalR pour par exemple envoyer un message à un utilisateur, quelque soit la page où il est, pour lui dire qu’un de ses documents a été supprimé.

Recherche