Les applications en temps réel

Les applications web temps réel

Écrit par , le
Analyste programmeur

Cet article a pour but de faire un tour d’horizon des technologies et des pratiques utilisées pour réaliser des applications web “temps réel”. En écrivant cet article je me suis vite rendu compte que le sujet était si vaste que j’aurais pu y consacrer plusieurs parties. J’espère tout de même avoir assez défriché le terrain et que cela donnera des pistes pour les personnes intéressées, que ce soit dans le cadre professionnel ou pour des projets personnels.

Qu’est-ce que le web temps réel ?

Le web traditionnel fonctionne de la manière suivante : le client (le navigateur internet) envoi une requête au serveur. Le serveur, après avoir traité cette requête, retourne la réponse au client. On parle ici de mode PULL puisque c’est le client qui va chercher l’information.

Le web temps réel utilise le mode PUSH. Une fois que le client a accédé à une page web (de manière traditionnelle en PULL), par exemple www.monsiteentempsreel.com, le serveur peut par la suite en fonction d’événements envoyer des informations au client et vice et versa sans avoir à recharger la page. Attention à ne pas confondre avec l’ajax, même si les informations peuvent être récupérées du serveur sans recharger la page, c’est bien le client qui fait la demande, donc PULL.

Petit précision, je ne vais pas parler ici de vrai temps réel, en informatique les systèmes temps réels sont utilisés pour contrôler des mécanismes physiques tels qu’une voiture ou un avion et doivent répondre en quelques millisecondes, ce qui n’est pas le cas ici puisque nous sommes en partie tributaire du réseau. Un temps de réponse moyen est de l’ordre de quelques centaines de millisecondes entre le moment ou un événement est déclenché sur un serveur et que le client reçoit la réponse.

Exemple d’applications en temps réel.

L’exemple typique est le système de chat. On peut également citer les notifications ou publications qui apparaissent automatiquement sur les réseaux sociaux.

Les outils de collaboration utilisent également beaucoup ce principe, entre autre :

  • Google Documents lorsque plusieurs personnes peuvent éditer le même document en simultané.
  • Slack, un système de communication collaboratif, permettant de gérer différents canaux de communications entre personnes et recevoir des notifications provenant d’applications tiers.
  • Trello, un outil de collaboration utilisant la méthodologie Kanban.
  • Cloud 9 IDE, un outil de développement en ligne permettant à plusieurs développeurs de travailler sur un même projet.
  • Murally permet aux équipes créatives de brainstomer de manière visuel.

En règle général toutes les applications ayant un tableau de bord gagnent à être en temps réel plutôt que de devoir recharger la page. Par exemple toute application de finance affichant des informations relatives aux marchés financiers tel que Caplin.

Enfin le web temps réel va être de plus en plus utilisé pour les objets connectés à mesure que l’internet des objets va se populariser (Internet Of Things).

Comment ça marche?

Très bien, maintenant, comment est-ce que cela fonctionne ? Puisque chez HPJ nous sommes spécialisés dans les applications web je vais rester dans cette optique et mettre de côté les applications mobiles, même si les principes restent similaires.

En ce moment, et ce depuis quelques années, une configuration se démarque : WebSocket + Node.js. WebSocket est un protocole full-duplex permettant d’établir une communication permanente entre le client et le serveur. Ce protocole est maintenant supporté par tous les navigateurs (à condition d’être à jour petits chenapans!!).

Mais avant l’apparition de Websocket, un ensemble de techniques rassemblées sous le terme générique COMET étaient utilisées pour “simuler” un système de PUSH, cela pouvait être apparenté à un hack (en tout cas c’est mon avis) puisqu’il s’agissait de détourner certaines techniques de leur but initial.

Donc parmi ces techniques :

  • ajax polling : le client fait des requêtes ajax régulières au serveur. Par exemple, imaginons un blog avec une zone de commentaires. Toutes les secondes le client demande au serveur s’il y a de nouveaux commentaires disponibles. Si oui le serveur retourne les nouveaux commentaires, si non le serveur ne retourne rien.
  • ajax long polling : même principe seulement au lieu que le client fasse des requêtes à intervalles réguliers, le serveur va attendre d’avoir du contenu pour répondre au client. Si l’on reprend l’exemple précédent : le client demande au serveur s’il y a de nouveaux commentaires, le serveur attend qu’on nouveau commentaire arrive et répond au client. Le client traite la réponse et envoie une nouvelle demande au serveur.

On voit que ces deux techniques ne sont pas efficaces. Elles consomment soit trop de bande passante inutile, soit trop de ressource serveur. Dans ces conditions la moindre augmentation du trafic devra être absorbée par de nouvelles machines.

  • Forever Iframe : une iframe cachée dans la page qui se charge petit à petit (en parlant de hack…).

Ne pas oublier Adobe Flash Socket, très utilisé historiquement dans les jeux ou chat en flash.

À peu près en même temps que les WebSocket et le web 2.0 est apparu HTML5 Server-Sent Events, malheureusement non supporté par Internet Explorer et seulement simplex, c’est à dire que cela peut être utilisé seulement pour récupérer du contenu du serveur (pour des notifications idéalement). WebSocket est plus complet et selon moi il n’y a pas vraiment d’intérêt à utiliser les Server Sent Events, mais puisque je suis bon joueur voici un article qui compare les deux technologies (oui l’article date).

Il existe également WebRTC permettant des communications temps réel peer-to-peer (donc entre deux clients sans passer par le serveur) mais surtout utile pour des communications audio ou vidéo, donc idéal pour des applications de visioconférence par exemple.

Comment on fait?

Il nous reste à choisir une techno permettant de faire du temps réel, c’est à dire un serveur supportant WebSocket. Le choix va dépendre de plusieurs facteurs, est-ce que vous avez déjà une application et vous voulez la rendre temps réel ou est-ce que vous partez de zéro ? Est-ce que vous êtes prêt à perdre du temps à changer de technologie ou est-ce que vous voulez rester dans un environnement familier ? Il y a trois possibilités :

Utiliser une plateforme supportant nativement le temps réel

C’est le cas de Node.js qui est la solution la plus populaire depuis quelques années. Dans ce cas il suffit d’utiliser un module qui a fait ses preuves, tel que Socket.io ou SockJs. Ces librairies contiennent deux parties, un package serveur s’exécutant via Node.js et un script javascript client permettant la communication avec le serveur. En fonction du navigateur, le script client va utiliser WebSocket si disponible ou tout autre technique le cas échéant (Flash ou ajax polling entre autre).

Il existe ensuite un tas de serveurs supportant WebSocket, Spray avec Akka pour Scala et Java tournant sur la JVM, SignalR pour les application en .NET, Jetty pour Java etc.

Il existe également des framework conçus pour faire nativement des applications temps réel. Le seul que je connaisse est Meteor pour Node.js mais il doit y en avoir d’autres.

Coupler à votre serveur Http un serveur temps réel.

Si vous avez une application existante vous pouvez tout à fait opter pour une solution hybride, garder votre serveur HTTP et ajouter un serveur pour le temps réel, par exemple Apache+Node.js. Néanmoins c’est un compromis car le temps gagné à ne pas réécrire l’application existante risque d’être perdu sur le long terme en maintenance, vous allez avoir deux applications à maintenir, réalisées avec deux langages différents, plus un lien entre les deux applications réalisé possiblement avec une file d’attente tel que Redis et RabbitMQ.

Utiliser un service hébergé

Il existe des services hébergés permettant de créer des applications temps réel. Cette solution ressemble à la solution hybride mais avec la partie temps réel hébergée sur un autre serveur. Ces services ont une api dans plusieurs langages permettant à votre application de communiquer avec. Bien sûr celles-ci sont la plupart du temps payantes ou avec plans gratuits limités. Parmi ces solutions : Firebase, Pusher, PuNDub.

Le cas PHP

Le problème avec PHP c’est que ce soit pour Apache, Nginx ou Lighttpd, aucun de ces serveurs ne supportent WebSocket. Dans le meilleur des cas ceux-ci permettent de jouer le rôle de proxy vers un serveur supportant, c’est le cas de Nginx depuis la version 1.2.13.

La solution est donc d’utiliser un serveur spécialisé en passant par le mode proxy de votre serveur d’application (typiquement Apache peut écouter sur le port 80 et votre serveur spécialisé sur le port 8080), ou d’utiliser un service hébergé.

Un des serveur spécialisé pour WebSocket les plus populaires est Ratchet. Je ne l’ai pas testé personnellement mais il semblerait qu’il s’en tire très bien niveau performance.

Et si le coeur vous en dit vous pouvez toujours implémenter votre propre serveur supportant WebSocket avec le langage de votre choix tel que décrit ici.

Conclusion

En définitive le futur semble prometteur pour Node.js qui s’est établi comme la norme avec Websocket pour les applications web temps réel. Le problème est que cette popularité fait passer sous le radar les autres alternatives. Certaines technologies semblent intéressantes mais il est parfois difficile de trouver des informations quand à leur réel comportement en production.

Liens utiles

Le blogue d’un spécialiste des applications temps réél : http://www.leggetter.co.uk

Une introduction succincte aux WebSockets avec socket.io : http://www.jonahnisenson.com/what-are-websockets-and-why-do-i-need-socket-io/

Une argumentation sur les choix technologiques chez Trello : http://blog.fogcreek.com/the-trello-tech-stack/

Explications plus détailles sur les techniques COMET : http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html

Un court tutoriel vidéo pour réaliser une app temps réel : http://knowthen.com/episode-10-building-realtime-applications-just-got-easy/

Les bienfaits de WebSocket détaillés sur le site de…WebSocket : https://www.websocket.org/quantum.html