Web-evolutie: van CGI naar Websockets (en hoe het u zal helpen uw cloudinfrastructuur beter te monitoren)

In de afgelopen paar jaar, websockets zijn min of meer een standaardcomponent geworden in alle moderne webapplicaties, maar waarom is dat en hoe zijn we hier gekomen? Belangrijker nog, hoe kunnen websockets u helpen uw cloudinfrastructuur effectiever te monitoren?

Vanwege de technische aard van dit onderwerp is het mogelijk om heel diep in de details te duiken. Maar ik zal proberen het op een relatief hoog niveau te houden en me te concentreren op de voordelen voor de gebruikers van onze cloudinfrastructuur.

De oude manier van werken

In de begindagen van het web was alles statisch. Als u interactie met een server nodig had (buiten het renderen van een statische pagina), moest u een soort CGI-script uitvoeren. Een typisch voorbeeld hiervan was zoiets als het aanmelden voor een mailinglijst. U voert uw e-mailadres in en drukt op ‘verzenden’, waarna u een aparte pagina ziet die de gegevens verwerkt. Dit was op zijn beurt een script dat de invoer aannam en op de server verwerkte.

Tegen de jaren '90 was server-side scripting aanzienlijk geëvolueerd. De technologie was geëvolueerd van het uitvoeren van eenvoudige taken naar het bouwen van volledig dynamische pagina’s. Programmeertalen zoals PHP, en meer geavanceerde server-side technologieën, zoals mod_perl, maakten veel geavanceerder webprogrammeren mogelijk. Hoewel deze technologieën belangrijk waren, evolueerden ze nog steeds rond het concept van het genereren van een pagina bij het laden. Eenmaal geladen, moest men de hele pagina herladen om de inhoud te vernieuwen.

Naarmate het web evolueerde, kwamen we in het AJAX/Web 2.0-tijdperk van de jaren ’00, webpagina's werden veel dynamischer en responsiever. U hoefde de pagina niet langer te herladen om de inhoud op het scherm bij te werken. Het enige wat u hoefde te doen was een aantal JavaScript-acties te starten. Veel AJAX-pagina's werden nog steeds aangedreven door PHP, maar konden met de introductie van client-side JavaScript dynamischer worden gemaakt.

Introductie van AJAX

Met de introductie van AJAX werd een voortdurende communicatie tussen de server en de client steeds belangrijker. Plotseling kon u een aanzienlijk aantal API-aanroepen hebben die werden gegenereerd door een individuele gebruiker op een bepaalde pagina. We doen dit op een 'pull'-manier, wat betekent dat de client met een bepaald interval (of op basis van een actie) updates van de server opvroeg.

Toen we de jaren ’10 binnengingen, was het gebruikelijk dat webpagina's volledig waren opgedeeld tussen de front-end (HTML/JavaScript/CSS) en de back-end (Ruby on Rails, Django enz.), die vaak op verschillende servers werden gehost. De manier waarop de front-end met de back-end communiceerde was via een API. De front-end was min of meer statisch. Met deze trend werd het doen van API-aanroepen naar de server een belangrijk knelpunt. Als u tien verschillende dingen van de server moest ophalen, betekende dit vaak dat u tien verschillende API-aanroepen moest doen, waarbij elke aanroep een aanzienlijke overhead en latentie met zich meebracht.

De moderne manier

Om dit probleem van latentie en overhead aan te pakken, werden websockets geïntroduceerd als onderdeel van HTML5 en geïmplementeerd in alle moderne browsers. In tegenstelling tot de traditionele 'pull'-benadering (d.w.z. de client die de server om wijzigingen vraagt), is een websocket, zoals de naam al doet vermoeden, een socket waarmee de server wijzigingen naar de client kan 'pushen'. Dus als er geen wijzigingen zijn, is er geen communicatie nodig. Omdat de client bovendien rechtstreeks met de server kan communiceren zonder de extra overhead van het openen en sluiten van verbindingen, wordt de applicatie een stuk responsiever.

Dit is precies hoe onze eigen webapplicatie is gebouwd. De eigenlijke applicatie is een statische pagina die een websocket-verbinding met de API opent. Zodra deze socket open is, kan de webapplicatie meldingen met wijzigingen van de server ontvangen. We sturen nog steeds commando's naar de RESTful API, maar we pushen meldingen van de server naar de client met behulp van de websocket.

Niet alleen voor webpagina's

Hoewel het meest voor de hand liggende scenario voor het ontvangen van updates via een websocket via een browser is, zijn er ook andere scenario's. Misschien schrijft u een tool die wijzigingen in uw architectuur monitort en op basis daarvan acties activeert. In dat geval kunt u uw applicatie aanzienlijk versnellen door gebruik te maken van onze websocket.

In onze Python-bibliotheek, pycloudsigma, hebben we ingebouwde ondersteuning voor websockets. We hebben zelfs een eenvoudig voorbeeld van hoe u dit kunt gebruiken om websocket-activiteiten te monitoren met slechts een paar regels code. Hier is een snelle demo van monitor_websocket_activity.py die de acties monitort die worden geactiveerd door de gebruikersinvoer in de web-app.
Voor meer informatie over onze diensten, bekijk onze Features.