Introducción

En una aplicación en tiempo real, rara vez trabajas con WebSockets de forma aislada. Los clientes necesitan mensajes dirigidos (enviados a un socket específico) así como eventos difundidos (lanzados a todos los clientes conectados). Además, la mayoría de productos reales siguen exponiendo una API REST — por ejemplo, cuando un usuario envía un formulario por HTTP, quieres que ese cambio aparezca al instante en cada sesión WebSocket abierta. Esta lección cubre exactamente eso: cómo enviar y difundir eventos desde un servidor Node.js, y cómo conectar un endpoint REST con tu capa de WebSocket para que ambas superficies se mantengan sincronizadas.

Enviar mensajes a un cliente vs difundir

Cada socket conectado tiene un id único asignado por el servidor. Puedes usar ese id para enviar un mensaje privado:

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

Si quieres que cada cliente conectado reciba el mismo payload, difunde en el namespace raíz — sin argumento de destino:

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

También existe `socket.broadcast.emit`, que envía a todos excepto al socket que disparó el evento. Esto es útil en salas de chat donde no quieres hacer eco del mensaje de vuelta al remitente.

Conectar un endpoint REST con eventos de WebSocket

El patrón típico es: el handler REST hace su trabajo (escribir en la base de datos, validar la entrada, etc.) y luego pide a la capa de WebSocket que envíe una actualización. Aquí tienes un ejemplo mínimo usando Express junto con 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);

El cliente HTTP obtiene el pedido creado en su respuesta REST, y cada pestaña del navegador conectada por WebSocket recibe el evento `order:new` al mismo tiempo. Una escritura, dos superficies.

Apuntar a rooms específicas

Cuando necesitas un control más fino que "todos" o "un socket", usa rooms. Una room es simplemente un canal con nombre al que los sockets se unen o del que salen:

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

`socket.to("orders")` llega a cada socket en esa room excepto al remitente. `io.to("orders").emit(...)` llega a todos en la room incluyendo al remitente. Las rooms son la forma estándar de implementar feeds por usuario, por equipo o por tema sin escribir lógica de enrutamiento personalizada.

Errores comunes

Llamar a `io.emit` dentro del handler REST está bien, pero no olvides que la respuesta REST y el emit de WebSocket son independientes — si la capa de WebSocket se cae, la petición HTTP seguirá devolviendo éxito. Para flujos críticos, envuelve la difusión en un try/catch y registra los fallos. Otro error frecuente es mezclar `socket.emit` (envía solo al socket actual) con `io.emit` (envía globalmente) asumiendo que se comportan igual. Elige el que coincida con tu intención. Por último, nunca confíes en el `socket.id` enviado desde el cliente — búscalo siempre en el lado del servidor a partir de tu sesión autenticada antes de enviar datos privados.

Resumen

Ahora tienes tres modos de entrega: `socket.emit` para el cliente actual, `io.emit` para difusión global y rooms para grupos específicos. Emparejar un handler REST con `io.emit` (o `io.to(room).emit`) es el patrón estándar de puente que mantiene las superficies HTTP y WebSocket consistentes. Mantén la difusión dentro del handler REST después de la lógica de negocio principal, maneja los fallos de WebSocket de forma elegante y verifica siempre las identidades en el servidor antes de enviar payloads privados.