Quando useresti WebSocket, SSE o long-polling invece del semplice HTTP?

Question

IT Interview Practice · Accepted Answer

Il semplice HTTP è **request/response**: il client chiede, il server risponde, fine. È una scelta poco adatta alle funzionalità **real-time** (chat, dashboard live, notifiche, editing collaborativo) dove è il *server* che deve fare push dei dati ogni volta che ha qualcosa di nuovo. Le opzioni sono modi per aggirare il modello a iniziativa del client dell'HTTP, lungo uno spettro di complessità:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

Il **long-polling** è il fallback che funziona ovunque: il client fa una richiesta normale che il server tiene aperta finché non ha dati, poi il client richiede immediatamente di nuovo. Approssima il push sul semplice HTTP ma spreca un ciclo di richiesta per ogni messaggio e aggiunge latenza.

Gli **SSE (Server-Sent Events)** sono uno stream **unidirezionale** (server → client) leggero e standardizzato su una singola risposta HTTP a lunga durata. Sono ideali quando solo il server fa push — feed live, notifiche, progress, streaming di token LLM. Sono semplici, girano su normale HTTP/2 (nessuna infrastruttura speciale) e si riconnettono automaticamente. Il limite: sono unidirezionali e solo testo.

I **WebSocket** promuovono una singola connessione HTTP in un canale TCP persistente e **full-duplex** dove entrambi i lati inviano in qualsiasi momento con overhead per messaggio minimo. Usali per un'interazione genuinamente bidirezionale e a bassa latenza: chat, giochi multiplayer, editor collaborativi, trading. Il costo è operativo — è una connessione stateful che proxy, load balancer e autoscaler devono essere configurati per gestire, e devi costruire da te riconnessione, heartbeat e backpressure.

**Regola pratica:** default al semplice HTTP; usa gli **SSE** per lo streaming server→client; ricorri ai **WebSocket** solo quando hai davvero bisogno di real-time bidirezionale; tieni il **long-polling** come fallback universale.

## Perché è importante

Scegliere un transport real-time è una classica decisione di design senior in cui la risposta ingenua ("usa i WebSocket per tutto") è di solito sbagliata. Chi conduce il colloquio vuole vedere che abbini lo strumento al *pattern di comunicazione* — unidirezionale vs bidirezionale, esigenze di latenza, volume dei messaggi — e che soppesi il **costo operativo** delle connessioni stateful a lunga durata: sticky session, scaling, timeout dei proxy e logica di riconnessione. Riconoscere che gli SSE spesso coprono "il server fa push degli aggiornamenti" in modo più semplice dei WebSocket, e che il long-polling resta un robusto fallback, segnala vera esperienza in produzione anziché il ricorso all'opzione più appariscente.

Perché è importante

Domande correlate