WebSockets para operaciones en tiempo real

Cuando la interfaz deja de ser un formulario y pasa a reflejar el estado de una operación física, el canal en tiempo real se vuelve parte del diseño. En Bodega Digital el frontend se comunicaba por WebSocket para que el operador viera qué estaba pasando y qué le tocaba hacer. Estas son las decisiones que importaron.

Qué problema resuelve el canal

Un sondeo periódico también «actualiza» la pantalla, pero multiplica peticiones y llega tarde. El WebSocket permite que el servidor empuje cambios cuando ocurren y que el cliente mantenga una conexión abierta mientras dura la sesión de trabajo.

Lo importante es tener claro qué se transporta: no un flujo infinito de datos, sinoeventos de estado relevantes para ese rol. El canal no es una base de datos en streaming.

El estado viene del servidor

El error clásico es construir el estado en el navegador: aplicar deltas y confiar en que el orden y la entrega son perfectos. En una operación real, el cliente se desconecta, el móvil se bloquea o la red del almacén tiene un hueco.

Por eso el cliente pide un estado inicial al conectar y después aplica cambios, pero siempre puede volver a pedir el estado completo. Los deltas aceleran la interfaz; el estado del servidor manda.

socket.onmessage = (message) => {
  const event = parse(message.data);
  switch (event.type) {
    case "task.updated":
      applyTaskUpdate(event.payload);
      break;
    case "task.expired":
      reconcile(event.payload);
      break;
  }
};

Autorización en el servidor, no en la interfaz

El RBAC no puede vivir en el cliente. Que la interfaz oculte un botón es una decisión de experiencia, no de seguridad. El servidor debe saber qué rol y qué tipo de operador tiene la conexión y filtrar tanto los eventos que envía como las acciones que acepta.

En la práctica, eso significa autenticar al conectar, asociar la conexión a una identidad y comprobar permisos en cada mensaje que muta estado. La interfaz se adapta al rol porque el servidor le da el contexto adecuado, no porque confíe en ella.

Reconexión y estado inicial

Una conexión WebSocket se cae. La pregunta no es si, sino cuándo. El cliente necesita reconectar con una estrategia acotada, y al volver debe recuperar el estado en lugar de asumir que no se ha perdido nada.

• Reconexión con espera creciente y un límite claro.
• Estado inicial completo después de cada reconexión.
• Identificadores de versión o de secuencia para detectar huecos.
• Un indicador visible de que la conexión no está viva.

Ese último punto es más importante de lo que parece: un operador que cree estar viendo el estado real cuando la pantalla está congelada toma decisiones peores que uno que ve un aviso de desconexión.

Frecuencia y contrapresión

No todos los cambios merecen un mensaje. Si un dispositivo emite decenas de actualizaciones por segundo, reenviarlas todas al navegador no aporta nada y puede saturar la conexión. Conviene agrupar, muestrear o enviar solo transiciones de estado.

El servidor también debe protegerse: límites de mensajes por conexión, validación de tamaño y un mecanismo para cerrar conexiones que no consumen. Un canal abierto es un recurso, no un detalle.

Probar el canal

Un WebSocket es difícil de probar si toda la lógica vive en el manejador del evento. Separar el parseo, la reducción de estado y la autorización en funciones puras permite probar el comportamiento sin abrir una conexión real.

Después, una prueba de integración con dos clientes y roles distintos detecta lo que las pruebas unitarias no ven: que un operador recibe eventos que no le corresponden o que la reconexión deja la pantalla en un estado imposible.

Cierre

El tiempo real en una interfaz operativa no va de la tecnología del canal, sino de la confianza: el servidor decide, el cliente muestra y el usuario sabe cuándo la información está al día. Si esa confianza se rompe, la interfaz más rápida sigue siendo una interfaz en la que no se puede trabajar.