Évolution du Web : du CGI aux Websockets (et comment cela vous aidera à mieux surveiller votre infrastructure cloud)

Au cours des dernières années, websockets sont devenus plus ou moins un composant standard dans toutes les applications web modernes, mais pourquoi en est-il ainsi et comment en sommes-nous arrivés là ? Plus important encore, comment les websockets peuvent-ils vous aider à surveiller plus efficacement votre infrastructure cloud ?

En raison de la nature technique de ce sujet, il est possible de plonger très profondément dans les détails. Mais j’essaierai de rester à un niveau relativement général et de me concentrer sur les avantages pour les utilisateurs de notre infrastructure cloud.

L'ancienne façon de faire les choses

Aux débuts du web, tout était statique. Si vous aviez besoin d'interagir avec un serveur (au-delà du rendu d'une page statique), vous deviez exécuter une sorte de script CGI. Un exemple typique de cela était l'inscription à une liste de diffusion. Vous saisissez votre adresse e-mail et appuyez sur ‘soumettre’, puis vous voyez une page distincte qui a traité les données. Il s'agissait à son tour d'un script qui récupérait la saisie et la traitait sur le serveur.

Dans les années ‘90, le scripting côté serveur avait considérablement évolué. La technologie était passée de l'exécution de tâches simples à la création de pages entièrement dynamiques. Des langages de programmation comme PHP, et des technologies côté serveur plus avancées, comme mod_perl, ont permis une programmation web beaucoup plus sophistiquée. Bien que ces technologies fussent importantes, elles évoluaient toujours autour du concept de génération de page lors du chargement. Une fois chargée, il fallait recharger toute la page pour rafraîchir le contenu.

À mesure que le web évoluait, nous sommes entrés dans l'ère AJAX/Web 2.0 des années ’00, les pages web sont devenues beaucoup plus dynamiques et réactives. Il n'était plus nécessaire de recharger la page pour mettre à jour le contenu à l'écran. Tout ce que vous aviez à faire était de déclencher des actions JavaScript. De nombreuses pages AJAX étaient encore alimentées par PHP, mais avec l'introduction du JavaScript côté client, elles pouvaient être rendues plus dynamiques.

Présentation d'AJAX

Avec l'introduction d'AJAX, la communication continue entre le serveur et le client est devenue de plus en plus importante. Vous pouviez soudainement avoir une quantité importante d'appels API générés par un utilisateur individuel sur une page donnée. Nous faisons cela en mode ‘pull’, ce qui signifie que le client demandait des mises à jour au serveur à un intervalle donné (ou en fonction d'une action).

Au début des années ’10, il était courant que les pages web soient complètement divisées entre le front-end (HTML/JavaScript/CSS) et le back-end (Ruby on Rails, Django etc.), qui était souvent hébergé sur des serveurs différents. La façon dont le front-end communiquait avec le back-end se faisait via une API. Le front-end était plus ou moins statique. Avec cette tendance, passer des appels API au serveur est devenu un goulot d'étranglement important. Si vous deviez récupérer dix éléments différents sur le serveur, cela signifiait souvent que vous deviez effectuer dix appels API différents, chaque appel entraînant une surcharge et une latence importantes.

La méthode moderne

Pour résoudre ce problème de latence et de surcharge, les websockets ont été introduits dans le cadre de HTML5 et implémentés dans tous les navigateurs modernes. Contrairement à l'approche traditionnelle du ‘pull’ (c'est-à-dire le client demandant des modifications au serveur), un websocket est, comme son nom l'indique, un socket par lequel le serveur peut ‘pousser’ (push) les modifications vers le client. Par conséquent, s'il n'y a pas de modifications, aucune communication n'est nécessaire. De plus, comme le client peut communiquer directement avec le serveur sans la surcharge supplémentaire liée à l'ouverture et à la fermeture des connexions, l'application devient beaucoup plus réactive.

C'est exactement ainsi que notre propre application web est construite. L'application réelle est une page statique qui ouvre une connexion websocket vers l'API. Une fois ce socket ouvert, l'application web peut recevoir des notifications du serveur contenant les modifications. Nous envoyons toujours des commandes à l'API RESTful, mais nous poussons les notifications du serveur vers le client à l'aide du websocket.

Pas seulement pour les pages web

Bien que le cas le plus évident pour recevoir des mises à jour à l'aide d'un websocket soit via un navigateur, il existe également d'autres cas. Peut-être écrivez-vous un outil qui surveille les changements de votre architecture et déclenche des actions basées sur cela. Dans ce cas, vous pouvez accélérer considérablement votre application en utilisant notre websocket.

Dans notre bibliothèque Python, pycloudsigma, nous disposons d'un support intégré pour les websockets. Nous avons même un simple exemple montrant comment vous pouvez utiliser cela pour surveiller les activités du websocket avec seulement quelques lignes de code. Voici une démonstration rapide de monitor_websocket_activity.py qui surveille les actions déclenchées par la saisie de l'utilisateur dans l'application web.
Pour plus d'informations sur nos services, consultez nos Fonctionnalités.