¿Qué es Signal R?
En el principio de los tiempos, cuando los desarrolladores pretendían implementar mensajería en tiempo real, cada uno “hacía lo que podía”. La práctica más común era utilizar ineficientes técnicas de sondeo con Ajax (long-polling) o eventos enviados por el servidor, las cuales no estaban contempladas en los servidores.
En 2013, .Net se propuso estandarizarlo y se creó una tecnología basada en WebSockets llamada SignalR (creación original 2011). Crearon librerías del lado cliente y del lado del servidor las cuales abstraían la lógica y las complicaciones que normalmente ocasionaban.
SignalR implementaba un API consistente para enviar y recibir mensaje en tiempo real.
En un principio, ningún navegador tenía implementado la tecnología WebSocket, por lo que se utilizaba jQuery para invocarlo, creando una estrecha dependencia.
Dando un salto hasta 2018, mucha de la funcionalidad que requería jQuery ya se podía lograr con JavaScript plano. Con la salida de nuevos frameworks front-end (Angular, React, Vue, etc), JavaScript tomó el relevo definitivo y desapareció la dependencia con jQuery.
Con la salida de .Net Core por parte de Microsoft, la compañía también quiso dar una vuelta de tuerca a SignalR. Y en este punto, es donde nos encontramos, ASP.NET Core SignalR.
Novedades SignalR en .NetCore
Librería Javascript/TypeScript del lado cliente
Uno de los grandes cambios fue eliminar la dependencia con jQuery. Esta librería, (con versiones para Javascript/TypeScript) se puede usar sin hacer referencia a jQuery, lo que permite su uso en frameworks como Angular, React y Vue. Como vendría siendo natural, también se puede utilizar para cualquier aplicación que utilice Node.js.
La adquisición del cliente se puede obtener por npm. Incluso, lo han alojado en los llamados Content Delivery Networks (CDNs) y como paquete Nuget.
Por aquí os dejo un poco de información al respecto:
Inyección de dependencias
SignalR proporcionó una clase global que incluía su propio solucionador de dependencias (ya que ASP .NET no tenía inyección de dependencias). Tras la incorporación de inyección de dependencias nativas a .NetCore, SignalR solo tuvo que aprovecharse de su implementación.
Protocolos de comunicación integrados y personalizados
ASP.NET Core SignalR permite utilizar protocolos de comunicación Json y MessagePack (protocolo binario el cual tiene cargas más pequeñas que Json, que se basa en texto).
Mirando hacia el futuro, SignalR implementa puntos de extensibilidad para permitir el uso de nuevos protocolos.
Escalabilidad
ASP.NET SignalR tenía soporte integrado para realizar un escalado horizontal utilizando Redis, Service Bus o SQL Server. Esto permitía que diferentes instancias de la misma aplicación ASP.NET SignalR se comunicaran entre sí para transmitir mensajes a los distintos clientes, independientemente de la instancia a la que estén conectados.
Esto fue bastante tedioso de implementar, agregó muchos gastos generales y tampoco se tenía muy claro de que las aplicaciones tuvieran muchas casuísticas de escalamiento horizontal. El resultado fue una funcionalidad de escalamiento compleja, ineficaz y que no funcionaba bien en muchos escenarios.
ASP.NET Core SignalR rediseñó el modelo de escalamiento horizontal, haciéndolo más simple y extensible. Ya no permite que un solo cliente se conecte a diferentes instancias del lado del servidor. Esto hace que se requieran sesiones fijas para garantizar la afinidad entre cliente-servidor que utilizan distintos protocolos de WebSockets.
Actualmente SignalR proporciona escalamiento horizontal a través de Redis. Si te interesa, Azure SignalR Service te puede echar una mano.
Reconexiones
Otra decisión de diseño que parecía una buena idea cuando salió SignalR para ASP.NET fueron las reconexiones automáticas. SignalR incluía lógica de reconexión tanto en los clientes como en el servidor.
Si se perdía una conexión, los clientes intentaban reconectar, el servidor almacenaba en búfer los mensajes no enviados y los enviaba cuando estos realizaban la reconexión. Esta implementación tenía errores, resultaba ineficaz y la implementación no tenía sentido para todas las aplicaciones.
En la actualidad ASP.NET Core SignalR no admite la reconexión automática ni el almacenamiento en búfer automático de mensajes. En cambio, depende de la aplicación cliente decidir cuándo debe volver a conectarse; y depende del servidor implementar el almacenamiento en búfer de mensajes si es necesario.
Estas son las novedades más notables sobre la “nueva era” de SignalR. Si tienes un poco más de curiosidad, por aquí te dejo algo de información: