Creación de aplicaciones en tiempo real con SignalR - Parte 1

El protocolo HTTP es la base de toda la comunicación a través de la web y ha satisfecho nuestras necesidades desde los primeros días. HTTP funciona en un modelo de solicitud y respuesta, en el que es necesario enviar una solicitud al servidor para obtener cualquier actualización desde allí.

Esto crea desafíos en el manejo de algunos escenarios en los que necesitamos datos en tiempo real: cuando un usuario abre una página web, debe actualizarse, y cuando hay un cambio en el servidor pero según la arquitectura HTTP, se debe enviar una nueva solicitud para obtener una actualización del servidor. Esto crea una mala experiencia para el usuario y varias solicitudes también pueden limitar el ancho de banda de la red. Hay muchos escenarios en tiempo real en los que necesitamos mostrar datos en vivo al usuario (como con información de Bolsa, resultados de juegos en vivo, aplicaciones de chat y otros).

Para controlar estos escenarios, usamos diferentes soluciones alternativas, con las que AJAX ayudó mucho. AJAX nos permite enviar una solicitud (relativamente muy pequeña) y actualizar la interfaz de usuario en función de la respuesta. Otros retos a los que nos enfrentamos son el diferente comportamiento de los navegadores en términos de funciones y soporte. Desde el punto de vista del rendimiento, la utilización de los recursos y la red del servidor son otros problemas, por lo que no podemos enviar a ciegas varias solicitudes al servidor. Del mismo modo, no podemos hacer que el usuario espere más mientras espera la actualización. Es responsabilidad del desarrollador usar la mejor opción/protocolo disponible para manejar la comunicación en tiempo real.

¿Qué es SignalR?

SignalR es una biblioteca de alto nivel que hace que el desarrollo de aplicaciones web en tiempo real sea súper fácil. Podemos escribir aplicaciones web en tiempo real usando AJAX como se discutió anteriormente, o podemos usar Forever Frame u otras soluciones personalizadas, pero estas son bastante complejas y se necesita una lógica diferente para diferentes escenarios. SignalR oculta todas las complejidades involucradas y funciona a la perfección en todos los navegadores, incluidas las diferentes versiones. Es muy potente y permite comunicaciones bidireccionales entre cliente y servidor. No es necesario que el servidor espere la solicitud del cliente para enviar la respuesta, sino que puede enviar lógicamente la respuesta cuando haya nuevos datos disponibles. Se encarga de la propia gestión de la conexión y nos permite transmitir/unidifundir mensajes a los clientes conectados.

Transport Mechanism

SignalR utiliza una de varias tecnologías para configurar las comunicaciones entre el cliente y el servidor. Web Socket, que se introdujo con HTML5, proporciona soporte bidireccional, pero no es compatible con todos los navegadores y versiones anteriores. Como no podemos garantizar qué navegador utilizará el usuario, no podemos confiar simplemente en esto, por lo que debe haber alguna forma que pueda implementar características similares en todos los navegadores. Para ello, SignalR permite utilizar múltiples tecnologías de transporte y seleccionar la más adecuada para el escenario.

Analicemos brevemente las tecnologías anteriores

Web Socket: esta es una nueva tecnología de comunicación que proporciona una verdadera comunicación bidireccional a través de una sola conexión TCP en la web. En otras palabras, si ambas partes (cliente y servidor) admiten el socket web, esto crea una conexión persistente entre ellas que puede ser utilizada por el cliente o el servidor para enviar los datos en cualquier momento. Como tal, esto es más eficiente, ocupa menos memoria y muestra la latencia más baja. Este es el protocolo preferido para una aplicación SignalR.

Eventos enviados por el servidor (también conocido como origen de eventos): esta es otra técnica introducida con HTML5 que permite al servidor enviar las actualizaciones al cliente cada vez que haya nuevos datos disponibles. Esta tecnología se utiliza cuando Web Socket no es compatible. Es compatible con la mayoría de los navegadores excepto IE.

Forever Frame: forma parte del modelo COMET y utiliza un iframe oculto en el navegador para recibir los datos de forma incremental desde el servidor. El servidor comienza a enviar los datos en una serie de fragmentos incluso sin conocer la longitud completa del contenido. Se ejecuta en el cliente cuando se reciben los datos.

Sondeo largo de AJAX: esta es la forma menos preferida en SignalR para configurar una comunicación entre el cliente y el servidor. Además, ¡también es el más caro de todos! Es parte del modelo COMET y, como su nombre indica, sigue sondeando el servidor para buscar actualizaciones. La solicitud que se envía al servidor está basada en AJAX, para minimizar el uso de recursos y proporcionar una mejor experiencia de usuario. Pero sigue siendo caro porque sigue sondeando el servidor para saber si hay actualizaciones o no.

Antes de continuar, analicemos los dos modelos diferentes utilizados para conectarse entre el cliente y el servidor: Conexión persistente y Hub

Conexión persistente: esta es una API de nivel inferior que nos permite enviar mensajes sin procesar a diferentes clientes. También podemos personalizar esto en función de los diferentes tipos de mensajes y los diferentes clientes, y también podemos enviar estos detalles con el mensaje. En palabras simples, por un lado nos da más control sobre la conexión y el envío de diferentes tipos de mensajes, mientras que por otro lado necesitamos escribir más código.

Hubs: estas son API de nivel superior que se basan en las conexiones persistentes. Los hubs ocultan todas las complejidades al desarrollador y nos proporcionan un modelo de estilo RPC simple con la función única definida.

Cómo usar SignalR

SignalR es bastante fácil de configurar y usar. Podemos instalar el paquete nuget de la siguiente manera:

O podemos ejecutar el siguiente comando a través de la consola del administrador de paquetes:

Install-Package Microsoft.AspNet.SignalR

Esto instala todos los componentes necesarios de SignalR. Una vez instalado, para comenzar a usarlo, debemos completar los siguientes pasos:

1- En primer lugar, tenemos que configurar en nuestra aplicación. Para eso necesitamos crear una clase llamada como Startup.cs y poner el siguiente código allí:

    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();
        }
    }

2- Cree una clase Hub que debería heredar de la clase Hub como:

public class MySignalRHub : Hub
{
    public void SendMessage(string message)
    {
        // Calls the call back function defined on client side
        Clients.All.SayHello("Hello !! Your Message : " + message);
    }
}

El concentrador es el núcleo de cualquier aplicación SignalR y es el concentrador el que facilita la comunicación entre el cliente y el servidor. Aquí el método SayHello es un método JavaScript (lo veremos a continuación) que se llama desde el Hub. El cliente llamará al método SendMessage. El concentrador proporciona el enlace y la serialización del modelo de forma predeterminada.

3- Ahora en el lado del cliente (digamos en Index.HTML), necesitamos agregar bibliotecas fluidas:

<script src="Scripts/jquery-1.6.4.min.js"></script>

<script src="Scripts/jquery.signalR-2.2.0.js"></script>

Las anteriores son bibliotecas jQuery y SignalR que son necesarias para un cliente JavaScript. La versión mínima de jQuery es 1,6.4.

4- Ahora, ¿cómo se conecta el cliente al método del servidor? Para eso, necesitamos incluir el proxy Hub que se genera dinámicamente. Con esto, se produce la comunicación entre el servidor y el cliente. Se incluye como:

<script src="signalr/hubs"></script>

Nota: El orden del archivo en el cliente debe ser el mismo que el de jQuery, jQuery SignalR y Hub proxy.

5- Contamos con todos los recursos necesarios en el cliente. Ahora necesitamos escribir el código para llamar al código del lado del servidor y proporcionar una función de devolución de llamada que se llamaría desde el servidor cuando el servidor reciba alguna actualización. Veámoslo en el código:

var hubproxy = $.connection.mySignalRHub;

Esta es la instancia de proxy que sería clave para la comunicación. Definamos el método de devolución de llamada como:

hubproxy.client.sayHello = function (message) {
    // Process your message
}

Ahora para llamar al método del lado del servidor como:

$.connection.hub.start().done(function () {
   $('#sendmessage').click(function () {
          // Call the Send method on the hub.
          hubproxy.server.sendMessage($('#tbmessage').val());                
   });
});

En el código anterior, hay dos cosas clave. Primero iniciamos el concentrador y cuando termina, solo agregamos el método click y llamamos al sendMessage del concentrador. No se puede llamar a esto antes de iniciar el hub.

Los anteriores son todos los pasos necesarios para la configuración mínima de una aplicación SignalR. Veamos aquí la representación pictórica de la comunicación entre cliente y servidor:

Nota: En el lado del cliente, tendremos que llamar al método independientemente de cómo esté escrito en el servidor, o de lo contrario no se llamará.

Conclusión

En esta publicación, analizamos las complejidades de escribir aplicaciones web en tiempo real y cómo SignalR simplifica ese proceso. A continuación, analizamos los conceptos de modelos de conexión, modelos de transporte y cómo configurar la infraestructura y empezar a trabajar con SignalR. Estén atentos a mi próxima publicación, donde cubriremos las ideas de SignalR con un ejemplo de la vida real.

Cree aplicaciones web modernas para cualquier escenario con sus marcos favoritos.Descargar Ignite UIhoy y experimente el poder de Infragistics controles jQuery/HMTL5.