Introduction

Dans une application temps réel, on travaille rarement avec les WebSockets de manière isolée. Les clients ont besoin de messages ciblés (envoyés à un socket précis) ainsi que d'événements diffusés (envoyés à chaque client connecté). De plus, la plupart des produits réels exposent encore une API REST — par exemple, lorsqu'un utilisateur soumet un formulaire via HTTP, on souhaite que ce changement apparaisse instantanément dans chaque session WebSocket ouverte. Cette leçon couvre précisément cela : comment envoyer et diffuser des événements depuis un serveur Node.js, et comment relier un endpoint REST à votre couche WebSocket afin que les deux surfaces restent synchronisées.

Envoyer des messages à un client ou diffuser à tous

Chaque socket connecté possède un identifiant unique attribué par le serveur. Vous pouvez utiliser cet id pour envoyer un message privé :

io.to(socket.id).emit("private:message", { text: "only you see this" });

Si vous voulez que chaque client connecté reçoive le même payload, vous diffusez sur le namespace racine — aucun argument de cible n'est nécessaire :

io.emit("announcement", { text: "Server restarts in 5 minutes" });

Il existe aussi `socket.broadcast.emit`, qui envoie à tout le monde sauf au socket ayant déclenché l'événement. C'est utile dans les salons de discussion où l'on ne veut pas renvoyer le message à l'expéditeur.

Relier un endpoint REST avec des événements WebSocket

Le pattern typique est : le handler REST fait son travail (écriture en base de données, validation des entrées, etc.), puis demande à la couche WebSocket de pousser une mise à jour. Voici un exemple minimal avec Express aux côtés de Socket.IO :

const express = require("express");
const http = require("http");
const { Server } = require("socket.io");

const app = express();
app.use(express.json());

const server = http.createServer(app);
const io = new Server(server);

app.post("/orders", (req, res) => {
  const order = { id: Date.now(), item: req.body.item, status: "created" };
  io.emit("order:new", order);
  res.status(201).json(order);
});

io.on("connection", (socket) => {
  console.log("client connected:", socket.id);
});

server.listen(3000);

Le client HTTP reçoit la commande créée dans sa réponse REST, et chaque onglet de navigateur connecté via WebSocket reçoit l'événement `order:new` en même temps. Une seule écriture, deux surfaces.

Cibler des rooms spécifiques

Quand vous avez besoin d'un contrôle plus fin que « tout le monde » ou « un socket », utilisez les rooms. Une room est simplement un canal nommé auquel les sockets rejoignent ou quittent :

io.on("connection", (socket) => {
  socket.join("orders");
  socket.to("orders").emit("order:new", order);
});

`socket.to("orders")` atteint tous les sockets de cette room sauf l'expéditeur. `io.to("orders").emit(...)` atteint tout le monde dans la room, y compris l'expéditeur. Les rooms sont le moyen standard d'implémenter des feeds par utilisateur, par équipe ou par thème sans écrire de logique de routage personnalisée.

Erreurs courantes

Appeler `io.emit` à l'intérieur du handler REST ne pose pas de problème, mais n'oubliez pas que la réponse REST et le emit WebSocket sont indépendants — si la couche WebSocket plante, la requête HTTP renvoie quand même un succès. Pour les flux critiques, enveloppez la diffusion dans un try/catch et journalisez les échecs. Une autre erreur fréquente consiste à mélanger `socket.emit` (envoie uniquement au socket courant) avec `io.emit` (envoie globalement) en supposant qu'ils se comportent de la même manière. Choisissez celui qui correspond à votre intention. Enfin, ne faites jamais confiance au `socket.id` envoyé par le client — récupérez-le toujours côté serveur depuis votre session authentifiée avant d'envoyer des données privées.

Résumé

Vous disposez désormais de trois modes de livraison : `socket.emit` pour le client courant, `io.emit` pour la diffusion globale, et les rooms pour les groupes ciblés. Associer un handler REST avec `io.emit` (ou `io.to(room).emit`) est le pattern standard de pont qui maintient la cohérence entre les surfaces HTTP et WebSocket. Gardez la diffusion dans le handler REST après la logique métier principale, gérez les échecs WebSocket avec élégance, et vérifiez toujours les identités côté serveur avant d'envoyer des payloads privés.