Habilitar las actualizaciones automáticas en una aplicación web mediante SignalR Service

Completado

A continuación, vamos a dejar de lado el sondeo para centrarnos en una aplicación que inserta las actualizaciones de datos (a medida que se producen) en los clientes conectados. Este nuevo diseño reduce el tráfico y hace que la interfaz de usuario sea más eficaz al solo actualizar a medida que cambian los datos. Las tres tecnologías que vamos a usar para ofrecer esta solución actualizada son Azure Cosmos DB, Azure Functions y SignalR.

• Azure Cosmos DB: Cuando los datos de la base de datos cambian, Azure Cosmos DB expone una fuente de cambios. La compatibilidad de la fuente de cambios en Azure Cosmos DB funciona a través de la escucha de los cambios de un contenedor de la base de datos. Luego muestra la lista ordenada de documentos modificados en el orden en el que se han modificado. Cuando la aplicación escucha la fuente de cambios, puede responder automáticamente a los cambios de datos.

• Azure Functions: La diferencia principal entre esta función y la función getStocks original es que, ahora, esta función se desencadena según los cambios en nuestros datos. En el ejercicio anterior, la función se ha desencadenado basándose en las solicitudes del cliente y ha recuperado todos los datos a través de un enlace de entrada de Azure Cosmos DB. El empleo automático del desencadenador de Azure Cosmos DB mejora la eficacia de la recuperación de datos. Azure Functions incorpora un enlace que ejecuta código cada vez que se actualizan los datos de una fuente de cambios de Azure Cosmos DB. Una vez que una función está escuchando a la fuente de cambios, el usuario puede trabajar con un subconjunto de los datos que simplemente representa cambios de datos.

• Azure SignalR: Este servicio proporciona comunicación bidireccional con una conexión SignalR en el cliente que escucha las difusiones de SignalR desde la aplicación de Azure Functions.

SignalR y conexiones persistentes

A diferencia del sondeo, un diseño más favorable incorpora conexiones persistentes entre el cliente y el servidor. El establecimiento de una conexión persistente permite al servidor insertar datos en el cliente a voluntad. La naturaleza a petición de la conexión reduce el tráfico de red y la carga en el servidor. SignalR permite agregar fácilmente este tipo de arquitectura a la aplicación.

SignalR es una abstracción de una serie de tecnologías que permite a la aplicación disfrutar de comunicación bidireccional entre el cliente y el servidor. SignalR controla automáticamente la administración de conexiones y permite difundir mensajes a todos los clientes conectados de forma simultánea, como un salón de chat. También se pueden enviar mensajes a clientes concretos. La conexión entre el cliente y el servidor es persistente, a diferencia de una conexión HTTP clásica, que se vuelve a establecer para cada comunicación.

Una ventaja fundamental de la abstracción que ofrece SignalR es la manera en que admite reservas de "transporte". Un transporte es un método de comunicación entre el cliente y el servidor. Las conexiones de SignalR comienzan con una solicitud HTTP estándar. Cuando el servidor evalúa la conexión, se selecciona el método de comunicación más adecuado (transporte). Cuando se empareja con una conexión persistente al cliente, la función puede ponerse en contacto con clientes individuales a petición, lo que constituye la base de una arquitectura de aplicaciones en tiempo real. Los transportes se seleccionan en función de las API disponibles en el cliente:

• HTML 5: En el caso de los clientes que admiten HTML 5, se usa el transporte de API de WebSockets de forma predeterminada.
• WebSockets: Si el cliente no es compatible con WebSockets, SignalR recurre a Server Sent Events (también conocido como EventSource).
• Otras tecnologías: En el caso de los clientes más antiguos, se usa sondeo largo de Ajax o Forever Frame (solo IE) para imitar una conexión bidireccional.

La capa de abstracción que ofrece SignalR proporciona dos ventajas a la aplicación. La primera es la perdurabilidad de la aplicación. A medida que la web evoluciona y surgen API superiores a WebSockets, no es necesario cambiar la aplicación. Podría actualizarse a una versión de SignalR que admitiera todas las nuevas API y no tendría que revisar el código de la aplicación.

La segunda ventaja es que SignalR permite que la aplicación se degrade gradualmente según las tecnologías compatibles del cliente. Si no admite WebSockets, se usa Server Sent Events. Si el cliente no puede controlar Server Sent Events, usa sondeo largo de Ajax y así sucesivamente.

Vamos a ver cómo se usa SignalR para difundir información desde una función que lee la fuente de cambios de Azure Cosmos DB.