Para hablar de WebSockets, es fundamental entender primero cómo funciona la comunicación en la web.

En lugar de usar términos complejos, te explicaré de forma sencilla qué ocurre cada vez que nos comunicamos en línea.

Tipos de Comunicación Web Más Comunes

A lo largo de la historia de la web, han surgido diferentes enfoques para que clientes y servidores intercambien información. Aquí te presento los más utilizados:

HTTP Polling

Imagina que estás en un mostrador de información, y cada pocos minutos te acercas a preguntar si ha llegado tu paquete.

Eso es el HTTP Polling. El cliente (tu navegador) envía peticiones al servidor de forma periódica, preguntándole si hay nuevas actualizaciones.

Es como un "tira y afloja" constante donde el cliente es quien inicia cada pregunta.

Long Polling

Ahora, piensa en el mismo mostrador, pero esta vez, el empleado te dice: "Quédate aquí, te avisaré en cuanto llegue tu paquete". Esto es Long Polling. El cliente envía una petición al servidor, y este la mantiene abierta. En lugar de responder de inmediato, el servidor espera hasta que haya una actualización o hasta que pase un tiempo límite. Una vez que responde (o se agota el tiempo), el cliente debe enviar una nueva petición para reanudar el ciclo.

Server-Sent Events (SSE)

Con los Server-Sent Events (SSE), el mostrador de información se convierte en un sistema de altavoces. Una vez que te registras, el empleado puede anunciar información directamente a todos los que están escuchando, sin que tengan que preguntar. Es una comunicación unidireccional del servidor al cliente, perfecta para enviar notificaciones o actualizaciones en tiempo real, como noticias o marcadores deportivos.

WebRTC

¿Alguna vez has hecho una videollamada desde tu navegador? Eso es gracias a WebRTC (Web Real-Time Communication). Esta tecnología permite la comunicación directa y en tiempo real entre navegadores, incluyendo video, audio e intercambio de datos. Es lo que hace posible que las aplicaciones utilicen el hardware de comunicación de tus dispositivos, como la cámara o el micrófono.

gRPC

Finalmente, tenemos gRPC. Piensa en él como un servicio de mensajería ultrarrápido y altamente eficiente, diseñado principalmente para que los diferentes componentes de un sistema (especialmente en el backend) se comuniquen entre sí. Utiliza HTTP/2 para una comunicación bidireccional y de alto rendimiento, ideal para microservicios y APIs internas que necesitan ser increíblemente rápidas.

Ahora que tenemos clara la base de la comunicación web, podemos abordar un problema común cuando configuras WebSockets para tu chatbot: ¿por qué no funciona de inmediato? El quid del asunto está en cómo el navegador (cliente) y el servidor WebSocket establecen su conexión inicial.

El Proceso de Conexión entre el Navegador y el Servidor WebSocket

Imagina que tu navegador es un poco perezoso y prefiere lo sencillo al principio. Aunque sabes que tu objetivo final es usar WebSockets (que ya tienes configurados en tu servidor con sus vistas, salas y reglas de acceso), el navegador no quiere gastar recursos en una comunicación compleja desde el primer momento.

Por eso, la primera petición que hace el navegador al servidor se realiza a través de Polling. El servidor responde usando este mismo sistema de Polling. Una vez que esta comunicación inicial "básica" se ha establecido, es cuando ocurre la magia: la conexión se "actualiza" o "mejora" a WebSocket.

Este proceso se gestiona automáticamente con una configuración de transporte como transport: ['polling', 'websocket']. Esto le dice al cliente que intente Polling primero y, si tiene éxito, que luego intente cambiar a WebSockets.

¿Adiós a los Errores de "Switching Protocols"?

Este mecanismo es crucial. Si tu chatbot no funciona, a menudo verás errores relacionados con "Switching Protocols". Estos errores ocurren precisamente porque la conexión inicial no se completó correctamente a través de Polling o la actualización a WebSocket falló. Al asegurar que tu configuración de transporte permite este inicio gradual, deberías resolver esos mensajes de error y permitir que tus WebSockets se establezcan correctamente.

¿Tiene sentido ahora por qué el navegador no se lanza directamente a los WebSockets y prefiere el "calentamiento" con Polling?