La tecnología que hace posible el tiempo real en la web: así funcionan los WebSockets

Hablar de “tiempo real” en el desarrollo de aplicaciones suena más ambicioso de lo que realmente es. No se trata de magia ni de infraestructura costosa: en muchos casos se reduce a elegir el mecanismo de comunicación adecuado para el problema que tienes delante. Y ese mecanismo, más frecuentemente de lo que parece, son los WebSockets.

Un chat que muestra mensajes al instante, un panel de métricas que se actualiza solo, una aplicación de logística donde el usuario ve en directo cómo cambia el estado de su pedido: todos estos escenarios comparten una necesidad que HTTP tradicional resuelve mal. No porque HTTP sea una mala tecnología, sino porque no fue diseñado para esto. HTTP nació para que el cliente pregunte y el servidor responda; no para que el servidor hable cuando tiene algo que decir.

En este artículo veremos qué son los WebSockets, cómo funcionan por dentro, cuándo tiene sentido usarlos y cuándo no, qué alternativas existen y cómo montar un ejemplo funcional de seguimiento de pedidos en tiempo real con Node.js y un cliente web.

Cuando el tiempo real deja de ser un extra

Hay aplicaciones que se pueden construir perfectamente con un modelo clásico de petición-respuesta: el usuario abre una página, el servidor devuelve los datos y la pantalla muestra el resultado. Si los datos cambian, el usuario recarga. Esto funciona bien para un blog, una tienda estática o un formulario de contacto.

Pero cada vez es más difícil encontrar aplicaciones modernas que encajen exclusivamente en ese esquema. Los usuarios esperan que las cosas ocurran sin que tengan que hacer nada: que el mensaje llegue sin pulsar “refrescar”, que el estado del pedido cambie en la pantalla sin recargar la página, que el panel de métricas muestre el número actualizado sin que nadie tenga que pedírselo al servidor.

La solución más obvia —y la más utilizada históricamente— es el polling: el cliente lanza peticiones al servidor cada cierto tiempo para comprobar si hay cambios.

	cliente → "¿hay algo nuevo?" → servidor → "no"
	cliente → "¿hay algo nuevo?" → servidor → "no"
	cliente → "¿hay algo nuevo?" → servidor → "sí, aquí tienes"
    	

Funciona, pero tiene un coste. Si el intervalo es corto, se generan decenas de peticiones por minuto aunque no haya nada nuevo. Si el intervalo es largo, la información llega tarde. Ninguna de las dos opciones es especialmente buena cuando la inmediatez importa, y ambas añaden carga innecesaria tanto al servidor como a la red.

Los WebSockets resuelven exactamente este problema cambiando el modelo por completo: en lugar de que el cliente pregunte repetidamente, se establece un canal persistente por el que tanto cliente como servidor pueden hablar en cualquier momento.

Qué son los WebSockets y cómo funcionan

Un WebSocket es una conexión persistente y bidireccional entre un cliente y un servidor. Una vez establecida, cualquiera de los dos extremos puede enviar mensajes sin que el otro haya pedido nada.

La conexión comienza con un handshake sobre HTTP. El cliente envía una petición especial con la cabecera Upgrade: websocket, el servidor responde con 101 Switching Protocols y, a partir de ese momento, la conexión deja de ser HTTP para convertirse en un canal WebSocket sobre la misma conexión TCP subyacente.

	GET /chat HTTP/1.1
	Host: ejemplo.com
	Upgrade: websocket
	Connection: Upgrade
	Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
	Sec-WebSocket-Version: 13

	HTTP/1.1 101 Switching Protocols
	Upgrade: websocket
	Connection: Upgrade
	Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    

Una vez completado el handshake, la conexión permanece abierta. El servidor puede enviar datos al cliente en cualquier momento, sin esperar una nueva petición. El cliente también puede enviar mensajes al servidor cuando lo necesite. Ambas direcciones funcionan de manera independiente y simultánea sobre la misma conexión.

Esto es exactamente lo que cambia la naturaleza del problema: ya no hay que preguntar si hay algo nuevo porque, cuando lo hay, llega directamente.

Qué ventajas ofrecen frente a otras estrategias

Las ventajas de los WebSockets frente al polling o las peticiones HTTP convencionales se hacen evidentes sobre todo en escenarios donde los datos cambian con frecuencia y la latencia importa:

• Menor latencia: el mensaje llega en cuanto el servidor lo emite, sin esperar al siguiente ciclo de polling.
• Menos tráfico redundante: no hay peticiones constantes que devuelvan “sin cambios”. La conexión está abierta, pero solo se transmiten datos cuando hay algo que transmitir.
• Bidireccionalidad real: el cliente puede enviar al servidor y el servidor puede enviar al cliente de forma independiente, sin que ninguno de los dos tenga que esperar turno.
• Mejor experiencia de usuario: la interfaz refleja el estado del sistema en tiempo real, sin recargas ni parpadeos.

Dicho esto, ninguna tecnología es la solución correcta para todo. Los WebSockets añaden complejidad —conexiones persistentes, gestión de estado, reconexión— que en muchos casos no merece la pena asumir.

Cuándo usarlos, y cuándo no

La pregunta relevante no es si los WebSockets son mejores que HTTP. Es si el problema que tienes delante requiere bidireccionalidad y baja latencia de forma sostenida.

Casos donde encajan bien:

• Chats y mensajería: los mensajes llegan en cuanto se envían, sin polling.
• Paneles de métricas o dashboards: los valores se actualizan en tiempo real sin recargar la página.
• Seguimiento en tiempo real: logística, transporte, entregas, posición de vehículos.
• Juegos multijugador: sincronización de estado entre jugadores con latencia mínima.
• Edición colaborativa: varios usuarios editan el mismo documento y ven los cambios de los demás al instante.
• Sistemas de soporte o presencia online: saber si un agente está disponible, si un usuario está escribiendo.
• Notificaciones push en aplicaciones web: alertas que llegan sin que el usuario tenga que hacer nada.

Casos donde probablemente no compensan:

• Apps con datos que cambian muy poco o que el usuario consulta de forma puntual.
• Backends sencillos donde un polling cada 30 segundos o Server-Sent Events ya resuelven el problema con mucha menos complejidad.
• Escenarios donde la comunicación es mayoritariamente unidireccional (solo el servidor envía): ahí SSE es una opción más simple y perfectamente válida.
• Entornos con restricciones de proxy o infraestructura donde mantener conexiones largas es problemático.

Alternativas a WebSockets

Antes de decidir usar WebSockets conviene conocer qué otras estrategias existen y en qué situaciones resultan más adecuadas:

La conclusión práctica es que los WebSockets brillan cuando necesitas bidireccionalidad y baja latencia de forma sostenida. Si solo necesitas que el servidor hable al cliente, Server-Sent Events (SSE) es una alternativa más sencilla con soporte nativo en la mayoría de navegadores. Y si los datos cambian pocas veces al día, el polling con un intervalo razonable es perfectamente suficiente.

Integración de WebSockets en tecnologías comunes

Navegador

El navegador expone una API nativa que no requiere ninguna librería externa. Se trabaja directamente con el constructor WebSocket y con los eventos onopen, onmessage, onclose y onerror:

	const ws = new WebSocket('ws://localhost:3000');

	ws.onopen    = () => console.log('Conectado');
	ws.onmessage = (event) => console.log('Mensaje:', event.data);
	ws.onclose   = () => console.log('Desconectado');
	ws.onerror   = (err) => console.error('Error:', err);

	ws.send(JSON.stringify({ tipo: 'saludo', contenido: 'Hola' }));
    

El objeto ws representa la conexión. Mientras esté abierta, cualquier llamada a ws.send() envía datos al servidor, y cualquier mensaje que el servidor emita llega a través de onmessage.

Node.js: ws vs Socket.IO

En el servidor, las dos opciones más comunes son ws y Socket.IO, pero no son lo mismo:

• ws es una implementación del protocolo WebSocket puro. Ligera, sin protocolo propio, sin magia adicional. Lo que envías es lo que llega. Es la opción adecuada si quieres control total y no necesitas funcionalidades extra.
• Socket.IO añade una capa de protocolo propia sobre WebSocket (con fallbacks automáticos, reconexión, salas, namespaces y eventos con nombre). Es más cómoda para aplicaciones complejas, pero ambos extremos —cliente y servidor— deben usar la librería Socket.IO. No es compatible con un cliente WebSocket nativo del navegador.

Para el ejemplo de este artículo usaremos ws porque queremos que el cliente sea JavaScript nativo del navegador, sin dependencias adicionales.

Consideraciones de despliegue

En producción hay algunos aspectos a tener en cuenta que no aparecen durante el desarrollo local:

• Proxies y balanceadores de carga deben estar configurados para permitir conexiones Upgrade. Nginx, por ejemplo, necesita las directivas proxy_http_version 1.1 y proxy_set_header Upgrade $http_upgrade.
• Sticky sessions: si hay múltiples instancias del servidor, el cliente debe conectarse siempre a la misma (o usar un broker compartido como Redis pub/sub para propagar los mensajes entre instancias).
• Heartbeats: muchos proxies e infraestructuras cierran conexiones inactivas pasado un tiempo. Un mecanismo de ping/pong periódico mantiene la conexión viva.

Buenas prácticas antes del código

Antes de abrir la primera conexión WebSocket en un proyecto real, conviene tener claras algunas decisiones de diseño que ahorran muchos problemas después:

Define bien los tipos de eventos. Un mensaje WebSocket es solo texto o binario. Si no le das estructura, acabarás con un canal por el que viajan objetos caóticos que nadie sabe cómo interpretar. Una convención sencilla como { type: string, payload: object, at: string } hace el código mucho más mantenible.

Gestiona la reconexión desde el cliente. Las conexiones WebSocket caen: reinicios del servidor, pérdidas de red, timeouts de proxy. El cliente debe ser responsable de reconectar, idealmente con backoff exponencial para no saturar el servidor si hay un problema generalizado.

Autentica al conectar. El handshake inicial es HTTP, así que puedes usar un token en la query string o validar una cookie de sesión. Una vez establecida la conexión, el canal ya no tiene cabeceras HTTP disponibles, así que la autenticación debe ocurrir antes o en el primer mensaje.

No saturar el canal. Enviar cada cambio de estado de cada entidad a todos los clientes conectados escala muy mal. Filtra qué recibe cada cliente: solo lo que le importa, solo cuando cambia algo relevante para él.

Piensa en logs y depuración. En HTTP puedes inspeccionar cada petición de forma independiente. En WebSockets el tráfico es un flujo continuo. Es importante loguear conexiones, desconexiones y errores, y tener alguna forma de inspeccionar los mensajes que se intercambian durante el desarrollo.

Ejemplo práctico: seguimiento de pedidos en tiempo real

Para ilustrar todo lo anterior con algo concreto, vamos a construir un servidor Node.js que emite actualizaciones de estado de un pedido en tiempo real, y un cliente web que las recibe y muestra en pantalla conforme llegan.

Captura de pantalla de una interfaz web de seguimiento de pedidos. En la parte superior aparece el título 'Seguimiento de pedido', un campo con el identificador 'ZX-1001' y un botón 'Seguir pedido'. Debajo se muestra el estado 'Conectado' y una línea temporal con cuatro etapas del pedido: 'Pedido recibido', 'En preparación', 'Enviado al transportista' y 'Pedido entregado', cada una con su hora correspondiente. La última etapa aparece resaltada en verde y marcada como completada, indicando que el pedido ha sido entregado correctamente.

El escenario utiliza las dos direcciones del canal. El servidor conoce varios pedidos, cada uno con su propia secuencia de estados. El cliente se conecta, el usuario introduce un código de pedido y el cliente envía un mensaje track_order al servidor. Este responde emitiendo los eventos de ese pedido uno a uno cada pocos segundos, igual que ocurriría si un proceso de backend estuviera actualizando el estado real de un envío. El cliente muestra cada evento en una línea de tiempo que va creciendo en vivo. El usuario puede pedir otro pedido en cualquier momento: el servidor cancela el ciclo anterior y empieza el nuevo.

Estructura del proyecto

	order-tracker-ws/
	├── client/
	│   └── index.html
	├── package.json
	└── server.js
    

Backend con Node.js

Primero instalamos la única dependencia:

	{
	  "name": "order-tracker-ws",
	  "version": "1.0.0",
	  "main": "server.js",
	  "scripts": { "start": "node server.js" },
	  "dependencies": { "ws": "^8.17.0" }
	}
    

	npm install
    

El servidor define un mapa de pedidos, cada uno con su propia secuencia de estados. En lugar de auto-emitir al conectar, espera a recibir un mensaje track_order del cliente. Cuando llega, cancela cualquier ciclo previo y arranca uno nuevo para el pedido solicitado. Los eventos se emiten con un intervalo aleatorio de entre 3 y 10 segundos para simular el ritmo impredecible de un proceso real. Si el código no existe, devuelve un evento de error estructurado para que el cliente pueda mostrarlo sin lógica especial:

	const http = require('http');
	const { WebSocketServer } = require('ws');

	const ORDERS = {
	  'ZX-1001': [
	    { type: 'order_created',    label: 'Pedido recibido',              status: 'pending'   },
	    { type: 'order_processing', label: 'En preparación',               status: 'active'    },
	    { type: 'order_sent',       label: 'Enviado al transportista',     status: 'active'    },
	    { type: 'order_delivered',  label: 'Pedido entregado',             status: 'success'   },
	  ],
	  'ZX-1002': [
	    { type: 'order_created',    label: 'Pedido recibido',              status: 'pending'   },
	    { type: 'order_processing', label: 'En preparación',               status: 'active'    },
	    { type: 'order_delayed',    label: 'Retraso en el envío',          status: 'warning'   },
	    { type: 'order_sent',       label: 'Enviado al transportista',     status: 'active'    },
	  ],
	  'ZX-1003': [
	    { type: 'order_created',    label: 'Pedido recibido',              status: 'pending'   },
	    { type: 'order_cancelled',  label: 'Pedido cancelado por el cliente', status: 'cancelled' },
	  ],
	};

	const server = http.createServer();
	const wss = new WebSocketServer({ server });

	wss.on('connection', (ws) => {
	  console.log('Cliente conectado. Total:', wss.clients.size);
	  let timer = null;

	  ws.on('message', (data) => {
	    const msg = JSON.parse(data.toString());
	    if (msg.type !== 'track_order') return;

	    if (timer) clearTimeout(timer);

	    const events = ORDERS[msg.orderId];
	    if (!events) {
	      ws.send(JSON.stringify({
	        type: 'error',
	        label: 'Pedido no encontrado',
	        status: 'error',
	        orderId: msg.orderId,
	        at: new Date().toISOString(),
	      }));
	      return;
	    }

	    let step = 0;

	    const scheduleNext = () => {
	      if (step >= events.length) return;
	      const delay = Math.floor(Math.random() * 7000) + 3000;
	      timer = setTimeout(() => {
	        const event = events[step++];
	        ws.send(JSON.stringify({ ...event, orderId: msg.orderId, at: new Date().toISOString() }));
	        scheduleNext();
	      }, delay);
	    };

	    const firstEvent = events[step++];
	    ws.send(JSON.stringify({ ...firstEvent, orderId: msg.orderId, at: new Date().toISOString() }));
	    scheduleNext();
	  });

	  ws.on('close', () => {
	    if (timer) clearTimeout(timer);
	    console.log('Cliente desconectado. Total:', wss.clients.size);
	  });
	});

	server.listen(3000, () => {
	  console.log('Servidor escuchando en ws://localhost:3000');
	});
    

Para arrancarlo:

	npm start
   

Cliente web

El cliente es un único fichero HTML con JavaScript nativo. Sin frameworks, sin librerías, sin bundler. Abre la conexión al cargar la página y espera a que el usuario introduzca un código de pedido. Al pulsar el botón, limpia la línea de tiempo y envía { type: 'track_order', orderId } al servidor. Los eventos llegan por onmessage y se van añadiendo a medida que el servidor los emite. Los errores de pedido no encontrado usan el mismo camino que el resto de mensajes, por lo que el cliente no necesita lógica especial para distinguirlos más allá de la clase CSS:

	<!DOCTYPE html>
	<html lang="es">
	<head>
	  <meta charset="UTF-8">
	  <title>Seguimiento de pedido</title>
	  <style>
	    body {
	      font-family: system-ui, sans-serif;
	      max-width: 600px;
	      margin: 40px auto;
	      padding: 0 16px;
	    }
	    form { display: flex; gap: 8px; margin-bottom: 16px; }
	    input {
	      flex: 1;
	      padding: 8px 12px;
	      border: 1px solid #d1d5db;
	      border-radius: 6px;
	      font-size: 1rem;
	    }
	    button {
	      padding: 8px 16px;
	      background: #6366f1;
	      color: white;
	      border: none;
	      border-radius: 6px;
	      cursor: pointer;
	      font-size: 1rem;
	    }
	    button:hover { background: #4f46e5; }
	    #badge {
	      display: inline-block;
	      padding: 4px 10px;
	      border-radius: 12px;
	      font-size: 0.85rem;
	      margin-bottom: 24px;
	    }
	    .connected    { background: #d1fae5; color: #065f46; }
	    .disconnected { background: #fee2e2; color: #991b1b; }
	    .connecting   { background: #fef9c3; color: #854d0e; }
	    .event {
	      position: relative;
	      padding: 12px 40px 12px 16px;
	      border-left: 4px solid #d1d5db;
	      margin-bottom: 12px;
	      background: #f9fafb;
	      border-radius: 0 8px 8px 0;
	    }
	    .event .icon {
	      position: absolute;
	      top: 10px;
	      right: 12px;
	      font-size: 1.1rem;
	      line-height: 1;
	    }
	    .event.pending   { border-color: #9ca3af; background: #f9fafb; }
	    .event.active    { border-color: #6366f1; background: #f5f3ff; }
	    .event.success   { border-color: #22c55e; background: #f0fdf4; }
	    .event.warning   { border-color: #f59e0b; background: #fffbeb; }
	    .event.cancelled { border-color: #ef4444; background: #fef2f2; }
	    .event.error     { border-color: #ef4444; background: #fef2f2; }
	    .event small { color: #6b7280; font-size: 0.8rem; }
	  </style>
	</head>
	<body>
	  <h1>Seguimiento de pedido</h1>

	  <form id="form">
	    <input id="orderInput" type="text" placeholder="ZX-1001" value="ZX-1001">
	    <button type="submit">Seguir pedido</button>
	  </form>

	  <div id="badge" class="connecting">Conectando…</div>
	  <div id="timeline"></div>

	  <script>
	    const badge      = document.getElementById('badge');
	    const timeline   = document.getElementById('timeline');
	    const form       = document.getElementById('form');
	    const orderInput = document.getElementById('orderInput');

	    const STATUS_ICONS = {
	      pending:   '⏳',
	      active:    '🔄',
	      success:   '✅',
	      warning:   '⚠️',
	      cancelled: '❌',
	      error:     '❌',
	    };

	    let ws;

	    function connect() {
	      ws = new WebSocket('ws://localhost:3000');

	      ws.onopen = () => {
	        badge.textContent = 'Conectado';
	        badge.className   = 'connected';
	      };

	      ws.onmessage = (event) => {
	        const data  = JSON.parse(event.data);
	        const entry = document.createElement('div');
	        entry.className = `event ${data.status ?? 'active'}`;
	        entry.innerHTML = `
	          <span class="icon">${STATUS_ICONS[data.status] ?? '•'}</span>
	          <strong>${data.label}</strong>
	          <br>
	          <small>${new Date(data.at).toLocaleTimeString('es-ES')}</small>
	        `;
	        timeline.appendChild(entry);
	      };

	      ws.onclose = () => {
	        badge.textContent = 'Reconectando…';
	        badge.className   = 'connecting';
	        setTimeout(connect, 2000);
	      };

	      ws.onerror = () => {
	        badge.textContent = 'Error de conexión';
	        badge.className   = 'disconnected';
	      };
	    }

	    form.addEventListener('submit', (e) => {
	      e.preventDefault();
	      const orderId = orderInput.value.trim().toUpperCase();
	      if (!orderId || ws?.readyState !== WebSocket.OPEN) return;
	      timeline.innerHTML = '';
	      ws.send(JSON.stringify({ type: 'track_order', orderId }));
	    });

	    connect();
	  </script>
	</body>
	</html>
    

Para probarlo, arranca el servidor con npm start, abre client/index.html en el navegador e introduce cualquiera de los códigos disponibles (ZX-1001, ZX-1002, ZX-1003). Los eventos irán apareciendo en tiempo real. Prueba a cambiar de pedido a mitad de un ciclo: el servidor cancela el anterior y empieza el nuevo de inmediato.

	[Conectado]

	ZX-1001 → Seguir pedido

	  Pedido recibido          10:42:01
	  En preparación           10:42:04
	  Enviado al transportista 10:42:07

	ZX-1003 → Seguir pedido   ← cambio a mitad de ciclo

	  Pedido recibido          10:42:09
	  Pedido cancelado         10:42:12
    

Qué estamos aprendiendo realmente

Este ejemplo es pequeño, pero resume bien lo que implica trabajar con WebSockets:

La bidireccionalidad tiene que ser visible para que tenga sentido. La versión anterior solo mostraba el servidor hablando al cliente. Con el formulario, el canal funciona en ambas direcciones: el cliente envía track_order, el servidor responde con eventos. No es solo una demostración técnica; es el patrón real que usan chats, dashboards o sistemas de notificación.

Separar eventos, estado y transporte. El servidor no sabe nada de la interfaz; el cliente no sabe nada de cómo se genera el estado del pedido. Se comunican a través de mensajes con estructura definida (type, label, orderId, at). Esa separación es lo que hace el código extensible: añadir un nuevo tipo de evento o un nuevo pedido no requiere tocar la lógica del otro extremo.

El estado local puede desincronizarse. Si el cliente se desconecta durante el proceso y reconecta, tendrá que volver a pedir el pedido porque el servidor no tiene memoria de qué estaba enviando. En un sistema real, el servidor debería poder rehidratar el estado desde una base de datos cuando un cliente reconecta, o el cliente debería guardar el último orderId para pedirlo automáticamente al volver a conectar.

Las conexiones son recursos. El servidor mantiene una entrada en wss.clients por cada cliente conectado. Si hay miles de clientes simultáneos, eso tiene impacto en memoria y en descriptores de fichero. Escalar WebSockets horizontalmente requiere un broker compartido (Redis pub/sub, por ejemplo) para que los mensajes emitidos en una instancia lleguen a clientes conectados en otra.

Posibles problemas en producción

Trabajar con WebSockets en un entorno local es relativamente sencillo. Llevarlos a producción introduce algunos problemas que conviene anticipar:

Desconexiones inesperadas. La red es inestable. Proxies cierran conexiones inactivas. El servidor se reinicia. El cliente debe asumir que la conexión puede caer en cualquier momento y tener una estrategia de reconexión. El ejemplo usa un reintento fijo de 2 segundos; en producción es mejor usar backoff exponencial con un tope máximo.

Eventos duplicados. Si el cliente reconecta y el servidor reanuda el envío desde el principio (o desde un punto anterior), el cliente puede recibir el mismo evento más de una vez. Incluir un identificador único por evento permite que el cliente deduplique.

Orden incorrecto de mensajes. En redes con alta latencia o con múltiples conexiones paralelas, los mensajes pueden llegar en un orden diferente al que se enviaron. Si el estado depende del orden (cosa que suele ocurrir), conviene incluir un número de secuencia o un timestamp fiable.

Escalado. Un servidor WebSocket de proceso único puede manejar miles de conexiones, pero en cuanto necesitas más de una instancia del servidor, las conexiones de un mismo usuario pueden repartirse entre instancias distintas. La solución habitual es Redis pub/sub como capa de mensajería entre instancias, o un servicio gestionado de WebSockets como AWS API Gateway WebSocket, Ably o Pusher.

Conclusión

Los WebSockets no son una solución universal ni la alternativa obvia a HTTP. Son una herramienta específica para un problema específico: cuando necesitas que el servidor hable al cliente sin que el cliente tenga que preguntar, y cuando esa comunicación debe ser inmediata y bidireccional.

El polling resuelve muchos casos de manera más simple. SSE resuelve bien los escenarios unidireccionales sin la complejidad de mantener conexiones bidireccionales. Pero cuando el tiempo real es un requisito genuino —un chat, un dashboard en vivo, un sistema de tracking, edición colaborativa— los WebSockets ofrecen lo que ninguna de esas alternativas puede: un canal abierto en ambas direcciones, con latencia mínima y sin tráfico redundante.

El ejemplo de seguimiento de pedidos de este artículo es deliberadamente simple, pero deja ver las piezas que importan: la estructura de los mensajes, la gestión de la conexión desde el cliente, la limpieza de recursos en el servidor y los problemas que aparecen en cuanto el escenario se complica un poco. Esas piezas se repiten en cualquier sistema WebSocket real, independientemente del lenguaje o el framework.

Lo importante no es usar tiempo real porque suene bien. Es usarlo cuando mejora de verdad el producto.

Happy Building!!