5 façons de créer des applications en temps réel avec JavaScript

Il y a eu un moment où nous n'attendions pas trop des pages Web. Ce qui me rappelle que le site Web du film Space Jam est toujours sur Internet dans sa forme originale. Et il utilise un jeu de cadres. Pas iFrames. CADRES .

Space Jam

SPACE JAM, les personnages, les noms et tous les indices associés sont des marques de Warner Bros. © 1996 www.warnerbros.com

Warner Bros a quelques copies légèrement utilisées de Dreamweaver MX.

C'était en 1996. Nous sommes en 2019. Les temps ont changé et les utilisateurs attendent beaucoup plus des sites Web. Ils ne s'attendent pas seulement à ce qu'ils aient l'air bien, ils s'attendent à ce qu'ils soient pleins d'applications, et cela inclut d'être en temps réel.

Applications en temps réel

Les applications en temps réel sont celles qui réagissent aux modifications n'importe où dans le système d'une application connectée, et pas seulement à celles effectuées par l'utilisateur actuel.

L'exemple canonique du temps réel est une application de messagerie. Comme lorsque vous envoyez un message texte à un groupe d'amis sur le fait de se réunir pour les ailes le vendredi. Ensuite, mettez à jour tout le monde minute par minute sur votre progression du travail au bar. Merci, Trevor. Maintenant, nous sommes tous piégés dans un enfer de notification auquel nous ne nous sommes pas inscrits. JE VEUX JUSTE DES AILES.

En ce qui concerne le Web, il existe plusieurs modèles, technologies, bibliothèques et services différents que vous pouvez utiliser pour obtenir la fonctionnalité en temps réel généralement réservée aux applications natives. Je me suis récemment entretenu avec Anthony Chu qui m'a donné 5 façons de créer des applications en temps réel en JavaScript.

Anthony Chu #MSIgniteTheTour (@nthonyChu) | Twitter

Les derniers Tweets d'Anthony Chu #MSIgniteTheTour (@nthonyChu). Cloud Advocate @Microsoft. Azure, ASP .NET, Node.js… twitter.com

1. Interrogation longue

C'est à ce moment que l'application demande des mises à jour au serveur selon un calendrier. L'application «interroge» le serveur.

C'est l'équivalent net des enfants qui demandent «sommes-nous encore là?» toutes les cinq minutes. On dirait que nous y sommes encore, gamin? Demandez-moi encore une fois et je vous jure que je jetterai cette copie du "The Bee Movie" dans un fossé et que vous pourrez regarder l'herbe par la fenêtre comme nous le faisions quand j'étais enfant.

L'interrogation longue peut être implémentée manuellement avec n'importe quelle bibliothèque HTTP JavaScript, telle que jQuery ou Axios. Je n'ai jamais mis en œuvre cela moi-même. En faisant quelques recherches pour cet article, j'ai découvert que la meilleure façon de faire est d'utiliser une fonction récursive avec setTimeout. En effet, l'utilisation setIntervalne tient pas compte des demandes qui échouent ou expirent. Vous pourriez vous retrouver avec un tas d'appels ajax qui sont tous traités dans le désordre.

Voici un exemple du très bel article sur 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); })();

Il existe également des bibliothèques comme pollymer (à ne pas confondre avec Polymer) qui sont spécifiquement destinées à l'interrogation longue. Tu piges? «Sondage» ymer? Parce que ça fait des sondages? Est-ce que ce truc est allumé?

fanout / pollymer

Bibliothèque AJAX / longue interrogation à usage général. Contribuez au développement de fanout / pollymer en créant un compte sur GitHub. github.com

L'interrogation longue est bonne car elle fonctionne dans tous les navigateurs; même les super vieux. C'est mauvais parce que c'est super inefficace et pas exactement «en temps réel». Il a également des cas extrêmes (comme des échecs de demande) sur lesquels vous devez programmer comme nous l'avons déjà vu setInterval.

Une meilleure alternative à l'interrogation longue est les événements envoyés par le serveur ou SSE.

2. Événements envoyés par le serveur

Les événements envoyés par le serveur (SSE) sont similaires à l'interrogation longue dans la mesure où le client demande des informations au serveur. La grande différence est qu'avec SSE, le serveur maintient simplement la connexion ouverte. Lorsqu'un événement se produit et qu'il y a des informations à envoyer au client, le serveur envoie un événement au client.

Événements envoyés par le serveur

Traditionnellement, une page Web doit envoyer une demande au serveur pour recevoir de nouvelles données; autrement dit, la page demande des données à… developer.mozilla.org

Revenons à notre analogie du «voyage en voiture depuis l'enfer», ce serait comme si l'enfant disait «sommes-nous encore là?», Puis attendait patiemment votre réponse. Quatre heures de silence sublimes plus tard, vous arrivez à destination, faites demi-tour et dites «oui». C'est le scénario le plus irréaliste que j'aie jamais imaginé de ma vie.

SSE fait partie de l' EventSourceAPI du navigateur . Notez que selon caniuse.com, ni IE 11 ni Edge ne prennent en charge SSE. Cela en fait une technologie difficile à choisir, aussi intéressante soit-elle.

La bonne nouvelle est que pratiquement tous les navigateurs prennent en charge les Web Sockets.

3. Sockets Web

Web Sockets est une technologie qui facilite un véritable canal de communication bidirectionnel entre un client et un serveur. Contrairement aux événements envoyés par le serveur, qui consistent uniquement en une communication entre un serveur et un client, les Web Sockets peuvent être utilisés pour communiquer dans les deux sens.

Les Web Sockets sont, euh, assez verbeux. Ils ne sont pas vraiment le type d'API avec lequel vous souhaitez créer des applications. Un peu comme vous pourriez faire une requête HTTP avec l'objet XHR, mais OMG NO. J'ai googlé "PHP Web Socket Sample" et j'ai trouvé ce doozy dans la documentation PHP. J'ai zoomé complètement dans Chrome et j'ai à peine tout obtenu en une seule capture d'écran.

Et ce n'est que la partie serveur. Vous devez toujours câbler le navigateur.

Alors… c'est un non pour moi.

Heureusement, il existe de nombreuses bibliothèques qui résument encore plus les Web Sockets afin que vous n'ayez rien à écrire. L'une de ces bibliothèques s'appelle «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.