Comunicazione push e tempo reale

1. Il limite del modello pull

Tutte le interazioni HTTP viste finora — il server statico del capitolo 3, le API REST del capitolo 5 — hanno una caratteristica comune che è così ovvia da passare inosservata: è sempre il client a iniziare. Il browser chiede, il server risponde. Il server, per quanto sappia benissimo che qualcosa è cambiato, non ha alcun modo di dirlo a nessuno: può soltanto aspettare che qualcuno passi a chiedere.

Questo è il modello pull. La comunicazione è inizializzata dal client, che richiede periodicamente informazioni al server; le tecniche che lo realizzano sono il polling e il long polling. È semplice da implementare, ed è inefficiente. L'esempio elementare è il browser che ricarica una pagina ogni dieci secondi per avere gli aggiornamenti: nove volte su dieci scarica di nuovo quello che aveva già.

Il problema si vede bene appena si prova a costruire qualcosa di vivo. Una chat in cui i messaggi arrivano quando l'utente si ricorda di premere F5 non è una chat. Una dashboard di sensori che si aggiorna al prossimo giro di polling non è tempo reale. E poiché il progetto d'esame richiede esplicitamente almeno una funzionalità in cui è il server a iniziare la comunicazione, questo capitolo non è un approfondimento facoltativo: è la parte dello stack che vale otto punti su ventisette.

2. Il modello push: chi inizia la comunicazione

Nel modello push il server invia i dati al client appena sono disponibili: la comunicazione è server-initiated. Le tecniche sono i Server-Sent Events e le WebSocket. Il prezzo da pagare è la complessità: è più complesso, ma è più efficiente, perché si trasmette solo quando c'è davvero qualcosa da trasmettere.

Gli scenari tipici elencati a lezione sono quattro, e conviene tenerli a mente perché sono anche i quattro modi in cui il push entra in un progetto d'esame:

• Chat: i messaggi devono essere immediatamente disponibili a tutti i partecipanti;
• Notifiche: aggiornamenti immediati, come quelli dei social o della posta;
• Aggiornamenti in tempo reale: dashboard, trading, sensori;
• Streaming dati: audio, video, eventi live.

3. Polling

Il polling è, in generale, il processo per cui un dispositivo viene controllato ripetutamente per verificarne la disponibilità e, in caso contrario, si torna a un'altra attività. Nel contesto di HTTP il polling è la tecnica in cui un client invia periodicamente richieste al server per verificare se ci sono aggiornamenti o nuovi dati disponibili.

La sequenza è quella che ci si aspetta: richiesta, risposta con il dato corrente, attesa di un intervallo fisso, di nuovo richiesta, di nuovo risposta — spesso con lo stesso dato di prima, che è esattamente lo spreco. Solo alla terza o quarta iterazione la risposta contiene finalmente un valore nuovo.

Lato client bastano una fetch e un timer; lato server non serve nulla di speciale, perché la rotta è una normale rotta Express che risponde e chiude:

// examples/example-01-polling/index.html
function polling() {
  fetch("/events")
    .then(response => response.text())
    .then(data => {
      console.log("Data received:", data);
      document.body.innerHTML += "<p>" + data + "</p>";
    })
}

// examples/example-01-polling/server.js
app.get("/events", (req, res) => {
  res.send(`data: ${myEvent}\n\n`);
});

Il server, notatelo, non conserva alcuno stato relativo ai client: risponde e dimentica. È il modello HTTP puro del capitolo 3, applicato a ripetizione.

4. Long polling

Il long polling è una tecnica che permette di ridurre il numero di richieste fatte dal client per ottenere nuovi dati dal server. Il meccanismo si descrive in tre passi:

1. il client invia una richiesta verso il server;
2. il server non risponde finché non sono presenti nuovi dati;
3. ricevuta la risposta, il client invia una nuova richiesta.

Lato client la differenza rispetto al polling è una sola riga — la chiamata ricorsiva che riapre subito una nuova richiesta al posto del timer:

// examples/example-02-long-polling/index.html
function longPolling() {
  fetch("/events")
    .then((response) => response.text())
    .then((data) => {
      console.log("Data received:", data);
      document.body.innerHTML += "<p>" + data + "</p>";
      longPolling(); // Next request
    });
}

Lato server, invece, cambia tutto: il server deve tenere da parte le risposte non ancora inviate. Compare per la prima volta la struttura che ritroveremo in tutte le tecniche push — un array di client, popolato all'arrivo della richiesta e ripulito quando la connessione si chiude:

// examples/example-02-long-polling/server.js
let clients = [];
let myEvent = 0;

app.get("/events", (req, res) => {
  clients.push(res);
  req.on("close", () => {
    clients = clients.filter((client) => client !== res);
  });
});

setInterval(() => {
  clients.forEach((client) => {
    client.send(`data: ${myEvent++}\n\n`);
  });
}, 5000);

5. Server-Sent Events

I Server-Sent Events (SSE) permettono al server di inviare aggiornamenti automatici al client tramite una connessione HTTP unidirezionale, e sono ideali per le notifiche in tempo reale senza bisogno di richieste continue da parte del client. La connessione viene aperta una volta sola e resta lì: il server ci scrive dentro un evento dopo l'altro finché uno dei due la chiude.

Il client non usa più fetch, ma l'oggetto nativo EventSource, che si occupa da solo di aprire la connessione e di consegnare ogni messaggio al callback:

// examples/example-03-sse/index.html
function setupSSE() {
  const eventSource = new EventSource("/events");

  eventSource.onmessage = function (event) {
    console.log("Data received:", event.data);
    document.body.innerHTML += "<p>" + event.data + "</p>";
  };
}

Lato server la rotta diventa una rotta che non finisce mai. Gli header sono la parte che conta davvero, ed è quella su cui vale la pena soffermarsi:

6. WebSocket

Le WebSocket forniscono una connessione bidirezionale persistente tra client e server, e consentono comunicazioni in tempo reale con bassa latenza. Sono la scelta indicata per le applicazioni interattive come le chat o i giochi online, cioè per tutti i casi in cui anche il client ha qualcosa da dire in qualsiasi momento, non solo da ascoltare.

Un punto che a lezione viene sottolineato: è tramite il protocollo HTTP che si instaura la socket. La connessione nasce come una normale richiesta HTTP che chiede un upgrade, e solo dopo l'handshake il canale diventa una socket bidirezionale. È il motivo per cui nel codice server compare un gestore dell'evento upgrade:

// examples/example-04-websockets/index.html
function setupWebSocket() {
  const socket = new WebSocket("ws://localhost:3000");

  socket.onmessage = function(event) {
    console.log("Data received:", event.data);
    document.body.innerHTML += "<p>" + event.data + "</p>";
  };
}

document.addEventListener("DOMContentLoaded", (event) => {
  setupWebSocket();
});

// examples/example-04-websockets/server.js
let myEvent = 0;

server.on('upgrade', (request, socket, head) => {
  console.log('HTTP Upgrade request for WebSocket:', request.headers);
});

wss.on('connection', (ws) => {
  ws.on('close', () => {
    console.log('3) Client connection closed');
  });
});

setInterval(() => {
  wss.clients.forEach(client => {
    if (client.readyState === WebSocket.OPEN) {
      client.send(`data: ${myEvent++}`);
    }
  });
}, 5000);

Notate il controllo client.readyState === WebSocket.OPEN: con una connessione persistente il client può trovarsi in stati intermedi (in apertura, in chiusura, chiusa) e scrivere su una socket che non è aperta è un errore. È la stessa preoccupazione del req.on("close") del long polling, espressa nel vocabolario delle WebSocket.

7. Le quattro tecniche a confronto

La tabella che chiude questa parte del laboratorio è la sintesi da tenere a mente: mette in fila tipo di connessione, direzione della comunicazione e uso tipico.

8. Socket.io e la chat di laboratorio

Socket.io è una libreria per la comunicazione a bassa latenza, bidirezionale e ad eventi tra client e server. Rispetto alle WebSocket "nude" cambia il modello mentale: non si ragiona più su messaggi da serializzare, ma su eventi con un nome, che si emettono e si ascoltano da entrambe le parti — la stessa idea dell'EventEmitter di Node, estesa attraverso la rete.

L'esercizio guidato è una chat in cui è possibile scambiare messaggi tra tutti gli utenti collegati. Si parte creando un progetto con npm init e aggiungendo le dipendenze:

npm install express
npm install socket.io

Lato server servono tre oggetti — l'applicazione Express, il server HTTP che la ospita e il server Socket.io agganciato a quest'ultimo:

// 1.
const express = require("express");
const http = require("http");
const { Server } = require("socket.io");

// 2.
const app = express();
const server = http.createServer(app);
const io = new Server(server);

Poi si gestisce la rotta radice restituendo l'index.html fornito e si avvia il server:

// 3.
app.get("/", (req, res) => {
  res.sendFile(join(__dirname, "public", "index.html"));
});

// 4.
server.listen(3000, () => {
  console.log("Server running at http://localhost:3000");
});

Connessione e disconnessione

Ogni volta che un utente si connette — cioè ogni volta che un client chiama la funzione io() — viene generato un evento connection; quando si disconnette viene generato un evento disconnect. Si gestiscono così:

io.on('connection', (socket) => {
  console.log('a user connected');
  socket.on('disconnect', () => {
    console.log('user disconnected');
  });
});

Lato client basta una riga dentro il tag script: const socket = io();. Lanciando il server e visitando la radice deve comparire il messaggio di connessione; alla chiusura della tab, quello di disconnessione.

Il giro completo di un messaggio

Qui sta il cuore dell'esercizio, ed è un ottimo esempio di come si ragiona con gli eventi. Al click sul bottone di submit il client emette l'evento, il server lo intercetta e lo ripropaga a tutti, ogni client lo riceve e lo appende alla lista.

$('form').submit((e)=>{
  e.preventDefault();
  socket.emit('chat message', $('#m').val());
  $('#m').val('');
  return false;
});

socket.on('chat message', (msg)=>{
  io.emit('chat message', msg);
});

socket.on('chat message', (msg)=>{
  $('#messages').append($('<li>').text(msg));
});

9. L'esercizio: estendere la chat

A partire dal codice fornito in exercises/exercise-01, l'esercitazione chiede di implementare cinque funzionalità. Vale la pena leggerle non come una lista di compiti ma come una piccola tassonomia di problemi che ricompaiono in ogni applicazione real-time — e che ricompariranno nel progetto d'esame.

Verifica le tue conoscenze