SignalR Core & SqlDependency

Notas del editor

• #4: Note: The original version of SignalR was designed around long polling (note that back in the day support for websockets was not as common as it is today – it was not supported by many web browsers, it was not supported in .NET Framework 4, it was not (and still isn’t) supported natively on Windows 7 and Windows 2008 R2).
• #5: En constante cambio, debido a que aún está en desarrollo.
• #7: No más dependencia con JQuery o librerías de terceros: El cliente será javascript puro, de hecho está hecho con TypeScript y como saben TS compila el código en javascript plano, entonces tenemos la garantía (por estar hecho con TS) que el cliente es cross-browser, cross-host y cross-OS en cualquier motor de JS que soporte ECMAScript3 en adelante. No más auto-reconnect con message replay: Debido a la los problemas en diseño, complejidad y performance que esto conlleva actualmente. Una de las razones a nivel de rendimiento es que el servidor debe mantener un buffer por conección para almacenar todos los mensajes y poder intentar reenviarlos de nuevo a al cliente cuando se reestablesca la conección. (https://github.com/SignalR/SignalR/search?p=1&q=ring+buffer&type=Issues&utf8=%E2%9C%93) Otro problema común con la reconección es que el message-id puede llegar a ser más grande que el mismo mensaje, debido a que la petición de reconección contiene el id del último mensaje recibido por el cliente y el token de los grupos, que a su vez contiene información de los grupos al que el cliente está suscrito. Entonces cuando ocurre la reconección el servidor tiene que enviar este message-id con cada mensaje para que el cliente pueda decirle al servidor cuál fue el último mensaje que recibió. Entonces entre más grupos el cliente esté suscrito más grande es el message-id y por ende el payload incrementa significativamente el tamaño de la petición.(https://github.com/SignalR/SignalR/issues/3811) Otro problema similar, es acerca de los tokens de los grupos, entre más grupos el cliente esté suscrito, más grande es el tamaño del token. El servidor necesita enviar al cliente cada vez que el cliente se una o deje un grupo. Cuando ocurre la reconección, el cliente envía de vuelta este token al servidor, el problema es que esta petición se hace via GET, y la url tiene un limite en el tamaño y este tamaño varía entre navegadores. Ahora, si necesitamos esta característica, será necesario implementarla nosotros mismos, manejando el evento Closed. No más multi-hub endpoints: En realidad era un sólo endpoint (url por defecto signalR/hubs) por lo tanto todo el trafico al invocar uno u otro hub pasaba por este único endpoint en una sola conección. Es decir, teníamos multiples hubs sobre una sola conección. Con SignalR Core cada hub tendrá una url (endpoint) especifica. No más escalamiento horizontal (built-in) (otra responsabilidad más que dejan para el usuario): Asp.Net SignalR tiene sólo una forma de escalamiento horizontal y es a través de un MessageBus, y para ello ofrece 3 implementaciones: Azure service bus, redis y Sql Server (broker). Sólo hay un escenario donde cualquiera de estas opciones funciona bien, y es cuando estamos usando SignalR como un server broadcast, porque el servidor controla la cantidad de mensajes que son enviados. Ahora, en escenarios colaborativos (client-to-client) o modelos altamente concurrentes, estas 3 formas de escalar pueden convertirse en un cuello de botella debido a que el número de mensajes crece con el número de clientes. SignalR Core deja abierta la implementación para escalar horizontalmente para que la maneje el usuario según sus necesidades (ya que esto va a depender mucho de cada escenario y del negocio) para que sea más "plug and play", de hecho, deja un ejemplo escalando con Redis Cache. Además un MessageBus no es la única posibilidad para escalar, como ya lo dije es un trade off, podría usarse por ejemplo, microservicios, modelo de actores, etc. Básicamente Asp.Net SignalR tiene como Golden Hammer al message bus para escalar horizontalmente, y ya sabemos acerca de este anti-pattern. Decisiones radicales??? No más multi-server ping-pong (backplane): Asp.Net SignalR replicaba todos los mensajes en todos los servidores a través del MessageBus, ya que un cliente podía estar conectado a cualquier servidor, lo cual genera un gran tráfico entre la granja de servidores. Con SignalR Core la idea es que un cliente esté "pegado" a un solo servidor. Hay un mapeo de cliente-servidor almacenado externamente que indica qué cliente está conectado a qué servidor. Por lo tanto cuando el servidor tiene que enviar un mensaje no tiene que hacerlo a todos los servidores, porque ya sabe a que servidor está conectado el cliente.
• #8: Formato binario para enviar y recibir mensajes: Con Asp.Net SignalR sólo se puede enviar/recibir en formato JSON. Host-agnostic: SignalR Core no depende más de Http, en su lugar se habla de conexiones como algo agnostico, por ejemplo podremos usar SignalR via TCP o Http. Asp.net SignalR sólo tiene Http host y por ende Http transports. EndPoints API: Permite soportar Host-agnostic y es básicamente el building block de SignalR Core. Se encuentra en el espacio de nombres Microsoft.AspNetCore.Sockets y es una clase abstracta con un método OnConnectedAsync que recibe un objeto Connection, el cuál permite implementar la capa de transporte para los protocolos diferentes a Http. De hecho la clase HubEndPoint implementa la clase EndPoint, ya que como dije anteriormente, la clase EndPoint no depende de Http sino del objeto Connection. Entonces la implementación del EndPoint en los Hubs, implementa las tecnologías que trabajan sobre Http, como Long Polling, Server Sent Events y WebSockets. Format agnostic (Multiple formats): Permite registrar los formatos que vamos a usar en el DI container y luego hacer un mapeo de los formatos disponibles para el mensaje que se resolverán en tiempo de ejecución. Esto permite tener diferentes clientes que hablan en diferentes formatos pero conectados al mismo endpoint. Soporte para WebSocket clients nativos: En Asp.Net SignalR tenemos que usar el cliente javascript para poder conectarnos al servidor, de lo contrario es practicamente imposible usar el servidor de SignarlR. Con SignalR Core podemos crear nuestros propios clientes si así lo preferimos, pero cómo ya lo dije anteriormente SignalR Core ya envuelve toda esta complejida con los EndPoints. TypeScript Client: Cómo lo mencioné anteriormente el cliente web es soportado por TS con todas las ventajas que esto nos ofrece. Escalamiento horizontal flexible y extensible: Como lo expliqué anteriormente, SignalR Core eliminó las 3 opciones de escalar que venían incorporadas y ahora es nuestra responsabilidad, sólo que ahora queda más abierto para escalar según nuestras necesidades.