Evoluzione del Web: da CGI a Websockets (e come ti aiuterà a monitorare meglio la tua infrastruttura cloud)

Negli ultimi anni, websockets sono diventati più o meno un componente standard in tutte le moderne applicazioni web, ma perché è così e come siamo arrivati fin qui? Più importante ancora, in che modo i websocket possono aiutarti a monitorare la tua infrastruttura cloud in modo più efficace?

A causa della natura tecnica di questo argomento, è possibile addentrarsi molto nei dettagli. Ma cercherò di mantenere le cose a un livello relativamente alto e di concentrarmi sui vantaggi per gli utenti della nostra infrastruttura cloud.

Il vecchio modo di fare le cose

Nei primi tempi del web, tutto era statico. Se avevi bisogno di interagire con un server (oltre al rendering di una pagina statica), dovevi eseguire una sorta di script CGI. Un tipico esempio era l'iscrizione a una mailing list. Inserivi il tuo indirizzo email, premevi 'invia' e poi vedevi una pagina separata che elaborava i dati. Questo a sua volta era uno script che riceveva l'input e lo elaborava sul server.

Negli anni '90, lo scripting lato server si era evoluto in modo significativo. La tecnologia era passata dall'esecuzione di compiti semplici alla creazione di pagine completamente dinamiche. Linguaggi di programmazione come PHP, e tecnologie lato server più avanzate, come mod_perl, hanno consentito una programmazione web molto più sofisticata. Sebbene queste tecnologie fossero significative, si sviluppavano ancora attorno al concetto di generazione della pagina al caricamento. Una volta caricata, era necessario ricaricare l'intera pagina per aggiornare il contenuto.

Con l'evoluzione del web, siamo entrati nell'era AJAX/Web 2.0 degli anni ’00, le pagine web sono diventate molto più dinamiche e reattive. Non era più necessario ricaricare la pagina per aggiornare il contenuto sullo schermo. Tutto ciò che dovevi fare era avviare alcune azioni JavaScript. Molte pagine AJAX erano ancora basate su PHP, ma con l'introduzione di JavaScript lato client, potevano essere rese più dinamiche.

Introduzione ad AJAX

Con l'introduzione di AJAX, è diventata sempre più importante la comunicazione continua tra il server e il client. All'improvviso si poteva avere una quantità significativa di chiamate API generate da un singolo utente su una determinata pagina. Questo avviene in modalità 'pull', il che significa che il client richiede aggiornamenti al server a un intervallo prestabilito (o in base a qualche azione).

Entrando negli anni ’10, era comune che le pagine web fossero completamente divise tra il front-end (HTML/JavaScript/CSS) e il back-end (Ruby on Rails, Django ecc.), che spesso era ospitato su server diversi. Il modo in cui il front-end comunicava con il back-end era tramite un'API. Il front-end era più o meno statico. Con questa tendenza, effettuare chiamate API al server è diventato un collo di bottiglia significativo. Se dovevi recuperare dieci cose diverse dal server, spesso significava dover fare dieci chiamate API diverse, con ogni chiamata che comportava un sovraccarico e una latenza significativi.

Il modo moderno

Per affrontare questo problema di latenza e sovraccarico, i websocket sono stati introdotti come parte di HTML5 e implementati in tutti i browser moderni. Contrariamente al tradizionale approccio 'pull' (ovvero il client che chiede modifiche al server), un websocket è, come dice il nome, un socket in cui il server può inviare ('push') le modifiche al client. Di conseguenza, se non ci sono modifiche, non c'è bisogno di alcuna comunicazione. Inoltre, poiché il client può comunicare direttamente con il server senza il sovraccarico aggiuntivo dell'apertura e della chiusura delle connessioni, l'applicazione diventa molto più reattiva.

Questo è esattamente il modo in cui la nostra web application è costruita. L'applicazione vera e propria è una pagina statica che apre una connessione websocket con l'API. Una volta aperto questo socket, l'applicazione web può ricevere notifiche dal server con le modifiche. Inviamo ancora comandi all'API RESTful, ma inviamo le notifiche dal server al client utilizzando il websocket.

Non solo per le pagine web

Sebbene il caso più ovvio per ricevere aggiornamenti tramite un websocket sia attraverso un browser, ci sono anche altri casi. Forse stai scrivendo uno strumento che monitora le modifiche alla tua architettura e avvia azioni basate su di esse. In tal caso, puoi velocizzare notevolmente la tua applicazione utilizzando il nostro websocket.

Nella nostra libreria Python, pycloudsigma, abbiamo un supporto integrato per i websocket. Abbiamo persino un semplice esempio su come puoi utilizzarlo per monitorare le attività del websocket con poche righe di codice. Ecco una rapida demo di monitor_websocket_activity.py che monitora le azioni attivate dall’input dell’utente nella web-app.
Per maggiori informazioni sui nostri servizi, dai un’occhiata alle nostre Funzionalità.