Real-Time

Il tempo, lo strano concetto, creato da noi, per descrivere come i cambiamenti influenzano la nostra percezione del mondo. Anche se è solo questo, un concetto, le nostre vite ruotano attorno ad esso e quindi è importante prenderlo in considerazione. L'ingegneria del software e lo sviluppo non sono diversi. Laddove Internet regna sovrano, è inconcepibile al giorno d'oggi, sviluppare un'app Web (o qualsiasi applicazione per quella materia) e fare clic su un pulsante di ricarica/F5/Ctrl+r per ottenere i dati più recenti. Le nostre applicazioni devono essere in tempo reale.
Che cos'è un applicazione in tempo reale (RTA), chiedi?

È un'applicazione che dà il senso dell'istantaneità, ad esempio se l'utente A modifica alcuni dati nell'applicazione, questa modifica sarà nota a tutti gli utenti nel più breve tempo possibile, senza la necessità di ricaricare l'applicazione.

Inoltre, il criterio di latenza che influenza i ritardi di consegna dei dati su un'applicazione (internet, elaborazione dati e così via) è molto importante quando si vuole implementare un'applicazione in tempo reale. A seconda di quanto possiamo rispettare le scadenze, la nostra domanda rientra in una delle tre seguenti categorie:

• Difficile in tempo reale, dove dobbiamo rispettare ogni singola scadenza nella nostra domanda. In caso contrario, si verifica un errore totale del sistema.
• Ditta in tempo reale, quando è tollerabile il mancato rispetto di alcune scadenze. Eventuali dati ricevuti oltre una scadenza sono inutili e, di conseguenza, la qualità delle domande è inversamente proporzionale alla quantità di scadenze mancate.
• Morbido in tempo reale, si riduce l'utilità dei dati ricevuti oltre la scadenza e quindi la qualità del sistema.

E la domanda che sorge spontanea è: dov'è il Web in tutto questo? O per essere più precisi, dove stanno le Web-app in queste tre categorie?
Bene, dovrebbe essere ovvio, le app Web non possono essere collocate nella prima categoria, poiché il Web ha sempre ritardi ed è quasi impossibile garantire ogni singola scadenza nella nostra applicazione a causa dell'entropia di Internet.
Una Web-app può, tuttavia, essere collocata in queste ultime categorie.
Dopo tutto questo parlare di RTA, sembra che ogni applicazione, al giorno d'oggi, debba includere una componente in tempo reale. Come già accennato, vogliamo che le nostre applicazioni siano reattive. Quando viene apportata una modifica, il suo effetto deve propagarsi a tutti gli utenti che utilizzano l'applicazione. Notifiche, messaggi di chat, feed di notizie, ecc. Tutti questi sono esempi di tempo reale nelle nostre applicazioni.
Tuttavia, la creazione di RTA non è necessariamente un gioco da ragazzi. Ciò comporta una maggiore complessità nelle nostre architetture poiché richiede più risorse che implica anche la sincronizzazione tra quelle. E anche il modo in cui dobbiamo gestire i nostri dati può essere piuttosto complicato (l'ordine tra i messaggi, i ritardi, la perdita e la ritrasmissione, ecc.).

Creazione di applicazioni in tempo reale

Ora parliamo di affari!

Come costruiamo applicazioni in tempo reale?

Abbastanza divertente, dal punto di vista architettonico, abbiamo già le basi, Server e Client. Tuttavia, la parte difficile è la comunicazione tra di loro. Comunichiamo già con il server tramite richieste HTTP e il server invia risposte HTTP. Tuttavia, vogliamo anche che il server sia in grado di inviarci messaggi. Introdurre Websocket e Server-Sent Events (SSE).
I Websocket e gli eventi inviati dal server sono modi per ottenere un percorso di comunicazione in qualche modo bidirezionale tra il server e i client.

WebSockets

I WebSocket utilizzano una connessione TCP (per WebSocket). È un protocollo HTTP aggiornato che consente la comunicazione bidirezionale tra un client Web e un server Web con un sovraccarico ridotto. (Avviso corretto, i websocket non sono qui (a partire da ora) un modo per sostituire HTTP, per favore non usare i websocket per fare i tuoi soliti post e ottenere.)
Come professionisti, Websockets ci offre una comunicazione full-duplex che supera la maggior parte dei firewall senza troppe riconfigurazioni. Possiamo scambiare qualsiasi tipo di dati e ha anche un buon modello di sicurezza (modello di sicurezza basato sull'origine).
Tuttavia, ci sono ancora proxy che non supportano il protocollo e i server Websocket necessitano di ottimizzazioni diverse rispetto ai normali server Web.

Eventi inviati dal server

SSE, che è spesso trascurato, sono normali richieste e risposte HTTP, proprio come il polling lungo senza l'overhead esagerato. La prima richiesta che deve essere inviata deve però avere un tipo di contenuto text/event-stream. Una volta che questa richiesta è stata inviata e il server riconosciuto, può inviare messaggi al client a piacimento.
Come vantaggi, SSE utilizza HTTP comune, la riconnessione e gli ID evento sono forniti dall'implementazione ed è un protocollo semplice.
Sfortunatamente, SSE non ha supporto binario ed è limitato al numero massimo di connessioni HTTP.

Websocket vs SSE

Dopo aver esposto questi due strumenti, le domande che sorgono sono:

Quando dovrei usare l'uno o l'altro?
Uno è migliore dell'altro?

Beh, dipende (non è mai così semplice, vero?).
I Websocket, come già detto, vengono utilizzati al meglio quando vogliamo davvero un percorso bidirezionale tra il server e il client, in genere quando stiamo costruendo un'app collaborativa, un gioco multiplayer, una chat, ecc.
Quando vogliamo solo ricevere aggiornamenti dal nostro server, ad esempio notifiche, flussi di aggiornamento come un feed, SSE sono fantastici poiché non richiedono molto lavoro e portano a termine il lavoro.

Menzioni d'onore

Sebbene abbiamo parlato del modo migliore per ottenere il tempo reale, ci sono altri strumenti che vale la pena menzionare.
I database in tempo reale sono, come suggerisce il nome, database preparati per gestire i dati utilizzando i principi del calcolo in tempo reale, quindi i dati sono prontamente disponibili per essere inviati al cliente se necessario e gestire più dati in generale. Esempi di questo tipo di database sono RethinkDB e Firebase offre anche un database in tempo reale.

Ad Summam

Penso che sia abbastanza per un articolo, vero? Quindi, per concludere, quando abbiamo parlato di tempo reale per le web-app, la componente in tempo reale dell'applicazione può essere descritta solo come morbida o rigida e anche se Real-Time è trendy e davvero utile, può essere difficile da programmare/mantenere o gestire. Infine, sia i Websocket che gli eventi inviati dal server sono modi per ottenere il tempo reale nelle nostre applicazioni. Scegli con attenzione, a volte potresti aver bisogno dell'uno o dell'altro. Se l'applicazione richiede una connessione bidirezionale completa tra il server e il client, utilizzare Websocket. Se hai solo bisogno di aggiornamenti usa SSE.

Assicurati di controllare il mio Repository GitHub fuori, per giocare con entrambi questi strumenti!

Grazie a tutti per aver letto questo articolo, non esitate a fornire suggerimenti per ulteriori miglioramenti o correzioni.
Scritto da Yoan Ribeiro