Aller au contenu principal

Introduction à Mercure

Comprendre la communication en temps réel et l'architecture publish/subscribe du protocole Mercure

Notions théoriques​

Le problème : comment envoyer des données en temps réel ?​

Dans une application web classique, la communication fonctionne dans un seul sens : le navigateur envoie une requête HTTP au serveur, et le serveur répond. Ce modèle, appelé requête-réponse, a une limite : le serveur ne peut pas prendre l'initiative d'envoyer des données au navigateur sans y être invité.

Imaginons un système de suivi de livraison. Si le statut d'une commande change (par exemple : "En préparation" → "Expédiée"), comment le client le sait-il sans recharger la page ?

Trois approches existent :

TechniqueFonctionnementAvantagesInconvénients
PollingLe navigateur interroge le serveur à intervalles réguliersSimple à mettre en placeRequêtes inutiles, latence, charge serveur
WebSocketsConnexion bidirectionnelle persistanteTemps réel vrai, bidirectionnelComplexe, protocole différent de HTTP
Server-Sent Events (SSE)Le serveur pousse des données vers le client via HTTPSimple, natif HTTP, reconnexion automatiqueUnidirectionnel (serveur → client uniquement)
info

Mercure utilise les Server-Sent Events (SSE) pour envoyer des mises à jour du serveur vers les clients. C'est une technologie standard du Web, supportée nativement par tous les navigateurs modernes — aucune bibliothèque JavaScript requise.

Architecture publish/subscribe de Mercure​

Mercure repose sur un modèle publish/subscribe (publier/s'abonner) articulé autour de trois acteurs :

  • Le Publisher (l'application Symfony) publie des mises à jour vers un Hub Mercure
  • Le Hub reçoit ces mises à jour et les redistribue aux abonnés
  • Les Subscribers (les navigateurs clients) s'abonnent au Hub pour recevoir les mises à jour en temps réel
[Symfony]  →  publie une Update  →  [Hub Mercure]  →  envoie via SSE  →  [Navigateurs]
astuce

Le Hub Mercure joue le rôle d'intermédiaire : il décharge Symfony de la gestion des connexions SSE persistantes. Symfony publie et oublie — c'est le Hub qui maintient les connexions clients.

Les topics​

Un topic est un identifiant unique sous forme d'URL qui permet de cibler précisément quels subscribers doivent recevoir une mise à jour.

https://monapp.fr/livraison/42   ← topic pour la livraison n°42
https://monapp.fr/livraison/*    ← topic pour toutes les livraisons (wildcard)

Chaque client s'abonne uniquement au topic qui le concerne — il ne reçoit que les mises à jour publiées sur ce topic.

remarque

Les topics sont de simples chaînes de caractères au format URL (IRI). Par convention, on utilise l'URL de la ressource concernée, mais le Hub ne fait aucune requête HTTP vers cette URL — c'est un simple identifiant.

Notre projet : SymfoLivraison​

Tout au long de ce tutoriel, nous allons construire SymfoLivraison, un système de suivi de livraisons en temps réel :

  • Une page d'administration permet de changer le statut d'une livraison parmi : En préparation, Expédiée, En cours de livraison, Livrée
  • Une page client affiche le statut en temps réel, sans rechargement de page

Quand l'admin change un statut → Symfony publie un événement Mercure → le Hub le retransmet → la page client se met à jour automatiquement.

Voici le flux de données dans SymfoLivraison :

[Admin]                    [Symfony]                    [Hub Mercure]             [Client]
   |                           |                               |                      |
   | → clique "Expédiée"       |                               |                      |
   | ────────────────────────→ |                               |                      |
   |                           | → new Update(topic, data)     |                      |
   |                           | → hub->publish($update)       |                      |
   |                           | ────────────────────────────→ |                      |
   |                           |                               | → SSE push           |
   |                           |                               | ───────────────────→ |
   |                           |                               |        | → met à jour |
   |                           |                               |        |   l'affichage|
remarque

Ce flux est unidirectionnel : Symfony publie, les clients reçoivent. Pour notre cas d'usage (suivi de livraison), c'est exactement ce qu'il nous faut : seul l'admin modifie les statuts.

Test de mémorisation/compréhension​


Quelle technologie Mercure utilise-t-il pour envoyer des données en temps réel ?


Dans l'architecture Mercure, quel est le rôle du Hub ?


Qu'est-ce qu'un topic dans Mercure ?


Quelle est la principale différence entre SSE et WebSockets ?


Dans le modèle publish/subscribe de Mercure, qui est le publisher ?


Pourquoi le polling est-il moins efficace que SSE pour du temps réel ?


Analyser l'architecture de SymfoLivraison​

Avant d'écrire du code, réfléchissez au flux de données de l'application.

Répondez aux questions suivantes :

  1. Qui est le publisher dans SymfoLivraison ?
  2. Qui sont les subscribers ?
  3. Quel serait un topic approprié pour suivre la livraison n°7 ?
  4. Pourquoi préférer Mercure au polling pour ce cas d'usage ?
📌 Une solution