Cuando el backend habla: tiempo real con WebSockets
Hola a todos me llamo Gonzalo Laguna, y hoy les hablare acerca de los WebSockets, será una introducción conceptual con una demo que nos ayudará a entender su potencial y su posible uso para aplicaciones en tiempo real.
Introducción
En muchas aplicaciones web todavía se sigue usando el mismo patrón de siempre: el frontend pregunta y el backend responde. Funciona, pero no es lo ideal cuando la información cambia constantemente.
Ahí es donde entran los WebSockets. En lugar de preguntar cada cierto tiempo si algo cambió, la aplicación mantiene una conexión abierta y el servidor avisa cuando hay novedades. El resultado es una experiencia mucho más fluida y natural para el usuario.
¿Para qué sirven realmente los WebSockets?
Los WebSockets son útiles cuando el tiempo importa. No solo por velocidad, sino por oportunidad: mostrar la información justo cuando ocurre, no después.
Son especialmente valiosos cuando:
- Los datos cambian con frecuencia
- Hay varios usuarios conectados al mismo tiempo
- El estado de algo debe reflejarse inmediatamente en pantalla
No reemplazan a las APIS REST, sino que las complementan.
Usos y utilidades más comunes
Te listo brevemente algunos casos en los que el uso de los WebSockets seria de mucha ayuda en un entorno real.
Notificaciones en tiempo real: Mensajes, alertas, aprobaciones, cambios de estado. No necesitas refrescar la página y sin consultas innecesarias.
Dashboards en vivo: Indicadores, métricas, estados de procesos o monitoreo.
Los datos se actualizan solos mientras el usuario observa.
Chats y mensajería: El caso clásico. La comunicación se siente instantánea y natural.
Estados de procesos: Cuando estás trabajando en algún proceso largo y necesitas que el usuario este informado del avance del proceso.
Estos procesos pueden ser: Cierres de nómina, cálculos en segundo plano o importaciones masivas.
¿En qué situaciones vale la pena usar WebSockets?
Los WebSockets no siempre son la mejor opción, y está bien decirlo.
Son útiles cuando:
- El sistema necesita reaccionar rápido
- El usuario espera feedback inmediato
- El polling empieza a generar ruido o carga innecesaria
- Hay muchos eventos, pero pocos realmente importantes
No son necesarios cuando:
- La data cambia poco
- Una llamada puntual es suficiente
- El tiempo real no agrega valor real al negocio
DEMO
Ya habiendo hablado sobre los beneficios de los WebSockets. Pasamos a una pequeña demo, para mostrar la implementación de esta tecnología usando .NET y Angular.
Se necesitan las siguientes tecnologías:
· Backend
o .NET 8
o SignalR: viene incluido en .NET, no necesitas instalar nada extra. Solo agregarlo a los servicios:
· Frontend 17
o Angular 17
o Instalar el cliente de SignalR: “npm install @microsoft/signalr”
Escenario
Se realizará una demo sencilla para observar el comportamiento de los WebSockets en acción:
- Los clientes se conectan automáticamente al HUB, el cual se encuentra alojado en el servidor.
- El servidor acepta las conexiones, registra a los clientes y les envía un mensaje de bienvenida.
- Los clientes cuentan con un botón que dispara una llamada al backend, solicitando el envío de una notificación.
- El controlador utiliza el HUB para enviar el mensaje a todos los clientes que mantienen una conexión activa con el servidor.
- Los clientes reciben el mensaje en tiempo real.
- Finalmente, la interfaz de usuario se actualiza automáticamente, sin necesidad de refrescar la página.
CÓDIGO
A nivel de código se mencionará las partes más importantes de la demo, estas están divididas en tres componentes importantes.
El HUB (Backend)
El HUB actúa como el centro de comunicación de la aplicación. Todos los clientes se conectan a este punto y, a través de él, pueden enviar y recibir mensajes en tiempo real.
- SendMessage: método encargado de enviar mensajes a todos los clientes conectados. En este caso, es utilizado desde el controlador para propagar los textos hacia los clientes.
- OnConnectedAsync: método que se ejecuta cuando un cliente establece la conexión con el HUB, permitiendo manejar la lógica inicial de conexión, como validaciones o mensajes de bienvenida.
El Controlador (Backend)
Nuestro controlador contará con un método encargado de invocar al HUB. Para ello, se utiliza IHubContext, el cual es inyectado en el controlador y nos permite acceder a los métodos del HUB desde fuera de él.
De esta forma, el controlador puede comunicarse directamente con el HUB y disparar los eventos necesarios para enviar mensajes a los clientes conectados.
El Servicio (Frontend - Angular)
Se debe crear un servicio encargado de gestionar toda la conexión del cliente con el HUB.
- StartConnection: se encarga de configurar la conexión hacia el HUB, para lo cual es necesario indicar la URL donde está expuesto el HUB en el backend.
- Una vez definida la configuración, se inicia la conexión utilizando dicha configuración.
El método ListenToMessages se encarga de registrar la escucha del evento ReceiveMessage que es emitido por el servidor.
Aquí es donde ocurre la magia: cuando el servidor envía el evento ReceiveMessage, todos los clientes que ya tienen configurada la escucha reciben el mensaje inmediatamente. De esta forma, la comunicación en tiempo real se da de manera directa, sin necesidad de refrescar la vista ni realizar nuevas solicitudes al backend.
Este mecanismo permite que los clientes reaccionen al instante ante cualquier evento que ocurra en el servidor.
DEMO EN ACCIÓN
En la siguiente imagen se puede observar cómo el cliente establece correctamente la conexión con el HUB.
Tal como se explicó previamente, el método OnConnectedAsync del HUB se ejecuta de forma exitosa cuando el cliente se conecta, lo que se refleja en el mensaje de bienvenida mostrado en pantalla.
Al hacer clic en el botón “Enviar notificación”, se dispara el flujo antes descrito:
El controlador recibe la petición, utiliza el HUB y este, a su vez, ejecuta el método SendMessage, encargado de enviar el mensaje a todos los clientes que tengan una conexión activa.
En la siguiente imagen se observa el aplicativo abierto en dos pestañas distintas. Aunque es la misma aplicación, funcionalmente representan dos clientes diferentes, por lo que el HUB envía el mensaje a ambos. Finalmente, cada cliente recibe el evento y muestra el mensaje en pantalla, todo en tiempo real, sin la necesidad de recargar la página.
Como dato adicional, se puede confirmar que la comunicación se realiza efectivamente mediante Sockets, lo cual puede verificarse desde la pestaña Network del navegador, donde se observa la conexión activa de tipo socket.
CONCLUSION
Esta demo muestra de forma simple cómo funciona la comunicación en tiempo real usando WebSockets. Un usuario ejecuta una acción, el backend la procesa y, a través del hub, el mensaje llega inmediatamente a otros clientes conectados. Sin refrescar la pantalla, sin esperar y sin lógica adicional en el frontend.
Este tipo de comunicación es especialmente útil cuando varias partes del sistema necesitan estar sincronizadas. WebSockets permiten que el servidor deje de ser solo reactivo y pase a notificar activamente cuando algo ocurre, lo que mejora tanto la experiencia del usuario como la eficiencia de la aplicación.
Para escenarios donde la información cambia constantemente o donde varios usuarios dependen del mismo estado, el tiempo real deja de ser un lujo y se convierte en una necesidad. Incluso una implementación simple, como esta demo, ya deja claro el valor que aporta este enfoque en aplicaciones modernas.
