5 formas de crear aplicaciones en tiempo real con JavaScript

Hubo un momento en el que no esperábamos demasiado de las páginas web. Lo que me recuerda que el sitio web de la película Space Jam todavía está en Internet en su forma original. Y usa un conjunto de marcos. No iFrames. MARCOS .

Space Jam

SPACE JAM, los personajes, los nombres y todos los signos relacionados son marcas comerciales de Warner Bros. © 1996 www.warnerbros.com

Warner Bros tiene algunas copias poco usadas de Dreamweaver MX.

Eso fue en 1996. Estamos en 2019. Los tiempos han cambiado y los usuarios esperan mucho más de los sitios web. No solo esperan que se vean bien, esperan que estén llenos de aplicaciones, y eso incluye ser en tiempo real.

Aplicaciones en tiempo real

Las aplicaciones en tiempo real son aquellas que reaccionan a los cambios en cualquier parte del sistema de una aplicación conectada, no solo a los realizados por el usuario actual.

El ejemplo canónico de tiempo real es una aplicación de mensajería. Como cuando le envías un mensaje de texto a un grupo de amigos sobre la reunión para las alas el viernes. Luego, actualice a todos minuto a minuto sobre su progreso desde el trabajo hasta el bar. Gracias, Trevor. Ahora estamos todos atrapados en un infierno de notificaciones en el que no nos registramos. SOLO QUERÍA ALGUNAS ALAS.

Cuando se trata de la web, existen varios patrones, tecnologías, bibliotecas y servicios diferentes que puede utilizar para obtener la funcionalidad en tiempo real que generalmente se reserva para las aplicaciones nativas. Recientemente me senté con Anthony Chu, quien me dio 5 formas en las que puedes crear aplicaciones en tiempo real en JavaScript.

Anthony Chu #MSIgniteTheTour (@nthonyChu) | Gorjeo

Los últimos Tweets de Anthony Chu #MSIgniteTheTour (@nthonyChu). Defensor de la nube @Microsoft. Azure, ASP .NET, Node.js… twitter.com

1. Sondeo largo

Esto es cuando la aplicación solicita actualizaciones del servidor en un horario. La aplicación está "sondeando" al servidor.

Este es el equivalente neto a que los niños pregunten "¿ya llegamos?" cada cinco minutos. ¿Parece que ya llegamos, chico? Pregúntame una vez más y te juro que arrojaré esta copia de “La película de la abeja” a una zanja y podrás mirar por la ventana al césped como lo hacíamos cuando era niño.

El sondeo largo se puede implementar manualmente con cualquier biblioteca HTTP de JavaScript, como jQuery o Axios. En realidad, nunca he implementado esto yo mismo. Al investigar un poco para este artículo, descubrí que la mejor manera de hacerlo es usar una función recursiva con setTimeout. Esto se debe a que el uso setIntervalno tiene en cuenta las solicitudes que fallan o se agota el tiempo de espera. Podría terminar con un montón de llamadas ajax que se procesan fuera de servicio.

Aquí hay un ejemplo del muy buen artículo sobre Tech Octave.

(function poll(){ setTimeout(function(){ $.ajax({ url: "server", success: function(data){ //Update your dashboard gauge salesGauge.setValue(data.value); //Setup the next poll recursively poll(); }, dataType: "json"}); }, 30000); })();

También hay bibliotecas como pollymer (que no debe confundirse con Polymer) que son específicamente para sondeos largos. ¿Consíguelo? "Encuesta" ymer? ¿Porque son encuestas? ¿Está encendido esto?

fanout / pollymer

Biblioteca de polling largo / AJAX de uso general. Contribuya al desarrollo de fanout / pollymer creando una cuenta en GitHub. github.com

El sondeo largo es bueno porque funciona en todos los navegadores; incluso los súper viejos. Es malo porque es muy ineficiente y no es exactamente "en tiempo real". También tiene algunos casos extremos extraños (como errores de solicitud) que debe programar como ya hemos visto setInterval.

Una mejor alternativa al sondeo largo son los eventos enviados por el servidor o SSE.

2. Eventos enviados por el servidor

Los eventos enviados por el servidor (SSE) son similares al sondeo largo en la medida en que el cliente solicita información al servidor. La gran diferencia es que con SSE, el servidor simplemente mantiene la conexión abierta. Cuando ocurre un evento y hay información para enviar al cliente, el servidor envía un evento al cliente.

Eventos enviados por el servidor

Tradicionalmente, una página web tiene que enviar una solicitud al servidor para recibir nuevos datos; es decir, la página solicita datos de… developer.mozilla.org

Volviendo a nuestra analogía del “viaje por carretera desde el infierno”, esto sería como si el niño dijera “¿Ya llegamos?” Y luego espera pacientemente su respuesta. Cuatro sublimes horas de silencio después llegas al destino, te das la vuelta y dices “sí”. Ese es el escenario más irreal que se me ha ocurrido en mi vida.

SSE es parte de la EventSourceAPI del navegador . Tenga en cuenta que, según caniuse.com, ni IE 11 ni Edge admiten SSE. Eso hace que sea una tecnología difícil de elegir, por interesante que sea.

La buena noticia es que prácticamente todos los navegadores son compatibles con Web Sockets.

3. Web Sockets

Web Sockets es una tecnología que facilita un verdadero canal de comunicación bidireccional entre un cliente y un servidor. A diferencia de los eventos enviados por el servidor, que es solo una comunicación del servidor a un cliente, los Web Sockets se pueden utilizar para comunicarse en ambas direcciones.

Los Web Sockets son, eh, un poco detallados. No son realmente el tipo de API con las que quieres crear aplicaciones. Es como si pudieras hacer una solicitud HTTP con el objeto XHR, pero OMG NO. Busqué en Google "PHP Web Socket Sample" y encontré este doozy en los documentos de PHP. Alejé todo el zoom en Chrome y apenas obtuve todo en una sola captura de pantalla.

Y esa es SOLO la parte del servidor. Aún tienes que conectar el navegador.

Así que… eso es un no para mí.

Afortunadamente, hay muchas bibliotecas que abstraen los Web Sockets aún más para que no tengas que escribir nada de esto. Una de esas bibliotecas se llama "SignalR".

4. SignalR

SignalR is a library that implements Web Sockets both in JavaScript AND .NET. On the server, you create what is known as a “hub” in SignalR. This hub sends and receives messages from clients.

Clients then connect to the hub (using the SignalR JavaScript library) and respond to events from the hub, or send their own events into the hub.

SignalR also falls back to long-polling whenever Web Sockets is unavailable. Although that’s not super likely unless you’re using IE 9 or lower.

Here is an example of setting up SignalR on the server…

using System; using System.Web; using Microsoft.AspNet.SignalR; namespace SignalRChat { public class ChatHub : Hub { public void Send(string name, string message) { // Call the broadcastMessage method to update clients. Clients.All.broadcastMessage(name, message); } } }

OK, ok. I know this is not an apples to apples comparison with the PHP example from above, but I’m trying to make a point here. Just go with it. Do it for me. I’m having a rough morning.

So SignalR makes it more fun to program Web Sockets, but you know what’s even more fun than programming them? Not programming them.

5. Azure SignalR

Often, when we want to set up real-time applications, building out a Web Socket server isn’t exactly a value-added activity. We do it, but only because we have to to get the real-time. We’d prefer that it “just worked”.

Azure SignalR is exactly that. It is a SignalR Hub that you can consume on demand as a service. That means that you only have to send and respond to events — which is what you’re after in the first place.

What is Azure SignalR

An overview of the Azure SignalR service.docs.microsoft.com

You create the SignalR Hub in Azure as an Azure Service, and then you just connect to it from the client and send/receive messages.

And now you know….

Check out the interview below with Anthony. We shot this one in Vegas while we were both at a conference and had a good time with a wig that I bought at Party City. Best 8$ I ever spent.