28 nov 2025·8 min
WebSockets vs Server-Sent Events: scegli quello giusto
WebSockets vs Server-Sent Events spiegati per dashboard live: regole semplici per scegliere, nozioni di scaling e cosa fare quando le connessioni cadono.
WebSockets vs Server-Sent Events spiegati per dashboard live: regole semplici per scegliere, nozioni di scaling e cosa fare quando le connessioni cadono.
Una dashboard live è fondamentalmente una promessa: i numeri cambiano senza che tu prema refresh, e quello che vedi è vicino a ciò che sta succedendo ora. Le persone si aspettano aggiornamenti rapidi (spesso entro uno o due secondi), ma si aspettano anche che la pagina resti calma. Niente sfarfallii, nessun grafico che salta, nessuno banner "Disconnected" ogni pochi minuti.
La maggior parte delle dashboard non sono app di chat. Spingono principalmente aggiornamenti dal server al browser: nuovi punti metrici, uno stato cambiato, un nuovo batch di righe o un avviso. Le forme comuni sono familiari: una bacheca di metriche (CPU, iscrizioni, revenue), un pannello avvisi (verde/giallo/rosso), una coda di log (ultimi eventi) o una vista di progresso (job al 63%, poi 64%).
La scelta tra WebSockets e Server-Sent Events (SSE) non è solo una preferenza tecnica. Cambia quanto codice scrivi, quanti casi limite strani devi gestire e quanto diventa costoso quando 50 utenti diventano 5.000. Alcune opzioni sono più facili da bilanciare. Alcune semplificano la logica di riconnessione e recupero.
L'obiettivo è semplice: una dashboard che rimane accurata, reattiva e che non diventi un incubo di on-call mentre cresce.
WebSockets e Server-Sent Events tengono entrambe una connessione aperta così una dashboard può aggiornarsi senza polling costante. La differenza è come funziona la conversazione.
WebSockets in una frase: una singola connessione duratura dove browser e server possono entrambi inviare messaggi in qualsiasi momento.
SSE in una frase: una connessione HTTP a lunga durata in cui il server spinge continuamente eventi al browser, ma il browser non invia messaggi di ritorno sullo stesso flusso.
Quella differenza solitamente decide cosa sembra più naturale.
Un esempio concreto: una bacheca KPI di vendita che mostra solo revenue, trial attivi e tassi di errore può funzionare tranquillamente con SSE. Uno schermo di trading dove un utente piazza ordini, riceve conferme e ottiene feedback immediato su ogni azione è molto più "a forma di WebSocket".
Indipendentemente dalla scelta, alcune cose non cambiano:
Il trasporto è l'ultimo miglio. Le parti difficili sono spesso le stesse in entrambi i casi.
La differenza principale è chi può parlare e quando.
Con Server-Sent Events, il browser apre una connessione a lunga durata e solo il server invia aggiornamenti lungo quel canale. Con WebSockets, la connessione è bidirezionale: browser e server possono inviare messaggi in qualsiasi momento.
Per molte dashboard, la maggior parte del traffico va dal server al browser. Pensa a "è arrivato un nuovo ordine", "la CPU è al 73%", "il conteggio ticket è cambiato". SSE si adatta bene a questa forma perché il client ascolta soprattutto.
WebSockets hanno più senso quando la dashboard è anche una console di controllo. Se un utente deve inviare azioni frequentemente (ack degli avvisi, cambiare filtri condivisi, collaborare), la messaggistica bidirezionale può essere più pulita che creare costantemente nuove richieste.
I payload dei messaggi sono di solito semplici eventi JSON in entrambi i casi. Uno schema comune è inviare una piccola busta in modo che i client possano instradare gli aggiornamenti in modo sicuro:
{"type":"metric","name":"active_users","value":128,"ts":1737052800}
Il fan-out è dove le dashboard diventano interessanti: un aggiornamento spesso deve raggiungere molti spettatori contemporaneamente. Sia SSE che WebSockets possono broadcastare lo stesso evento a migliaia di connessioni aperte. La differenza è operativa: SSE si comporta come una lunga risposta HTTP, mentre WebSockets passano a un protocollo separato dopo l'upgrade.
Anche con una connessione live, userai comunque normali richieste HTTP per cose come caricamento iniziale della pagina, dati storici, esportazioni, azioni create/delete, refresh auth e query pesanti che non appartengono al feed live.
Una regola pratica: tieni il canale live per eventi piccoli e frequenti, e usa HTTP per tutto il resto.
Se la tua dashboard ha solo bisogno di spingere aggiornamenti al browser, SSE di solito vince in termini di semplicità. È una risposta HTTP che rimane aperta e invia eventi di testo man mano che accadono. Meno componenti significa meno casi limite.
WebSockets sono ottimi quando il client deve parlare spesso, ma quella libertà aggiunge codice da mantenere.
Con SSE, il browser si connette, ascolta e processa eventi. Le reconnessioni e il retry di base sono integrati nella maggior parte dei browser, quindi passi più tempo sul payload degli eventi e meno sullo stato della connessione.
Con WebSockets, presto ti ritrovi a gestire il ciclo di vita del socket come una funzionalità di prima classe: connect, open, close, error, reconnect, e talvolta ping/pong. Se hai molti tipi di messaggio (filtri, comandi, ack, segnali di presenza), serve anche una busta messaggi e un instradamento sia sul client che sul server.
Una buona regola empirica:
SSE è spesso più facile da debug perché si comporta come HTTP normale. Di solito vedi gli eventi chiaramente nei devtools del browser e molti proxy e strumenti di osservabilità capiscono già bene HTTP.
WebSockets possono fallire in modi meno ovvi. Problemi comuni sono disconnect silenziosi dai load balancer, timeout di inattività e connessioni "half-open" dove una parte pensa di essere ancora connessa. Di solito noti i problemi solo dopo che gli utenti segnalano dashboard stale.
Esempio: se stai costruendo una dashboard vendite che ha bisogno solo di totali live e ordini recenti, SSE mantiene il sistema stabile e leggibile. Se la stessa pagina deve anche inviare interazioni rapide dall'utente (filtri condivisi, editing collaborativo), WebSockets può valere la complessità in più.
Quando una dashboard passa da pochi spettatori a migliaia, il problema principale non è la banda grezza. È il numero di connessioni aperte che devi mantenere vive e cosa succede quando alcuni di quei client sono lenti o instabili.
Con 100 spettatori, entrambe le opzioni sembrano simili. A 1.000 inizi a preoccuparti di limiti di connessione, timeout e frequenza di reconnessione. A 50.000 stai gestendo un sistema pesante di connessioni: ogni kilobyte extra bufferizzato per client si traduce in pressione reale sulla memoria.
Le differenze di scalabilità spesso emergono al load balancer.
WebSockets sono connessioni a lunga durata e bidirezionali, quindi molte configurazioni richiedono sessioni sticky a meno che tu non abbia un layer pub/sub condiviso e qualunque server possa gestire qualunque utente.
SSE è anch'esso a lunga durata, ma è HTTP semplice, quindi tende a funzionare più agevolmente con i proxy esistenti e può essere più facile da fare fan-out.
Mantenere i server stateless è di solito più semplice con SSE per dashboard: il server può pushare eventi da uno stream condiviso senza ricordare molto per client. Con WebSockets, i team spesso memorizzano stato per-connessione (sottoscrizioni, last-seen ID, contesto auth), il che rende la scalabilità orizzontale più complicata a meno di progettarlo per tempo.
I client lenti possono danneggiarti silenziosamente in entrambi gli approcci. Tieni d'occhio queste modalità di fallimento:
Una regola semplice per dashboard popolari: mantieni i messaggi piccoli, invia meno spesso di quanto pensi e sii disposto a scartare o coalescere aggiornamenti (per esempio, inviare solo l'ultimo valore di una metrica) così un client lento non rallenti tutto il sistema.
Le dashboard live falliscono in modi noiosi: un laptop va in sleep, il Wi‑Fi cambia rete, un dispositivo mobile attraversa un tunnel o il browser sospende una tab in background. La scelta del trasporto conta meno di come recuperi quando la connessione cade.
Con SSE, il browser ha la reconnessione integrata. Se lo stream si interrompe, riprova dopo un breve ritardo. Molti server supportano anche il replay usando un id evento (spesso tramite un header nello stile di Last-Event-ID). Questo permette al client di dire: "Ho visto l'evento 1042, mandami quello che mi sono perso", che è un percorso semplice verso la resilienza.
I WebSockets richiedono di solito più logica nel client. Quando il socket si chiude, il client dovrebbe riprovare con backoff e jitter (così migliaia di client non si riconnettono tutti insieme). Dopo la riconnessione serve anche un flusso chiaro di ri-sottoscrizione: autenticarsi di nuovo se necessario, rientrare nei canali giusti, poi richiedere eventuali aggiornamenti perduti.
Il rischio maggiore sono gap di dati silenziosi: l'interfaccia sembra a posto, ma è stale. Usa uno di questi pattern perché la dashboard possa provare di essere aggiornata:
Esempio: una dashboard vendite che mostra "ordini al minuto" può tollerare un breve gap se aggiorna i totali ogni 30 secondi. Una dashboard di trading no: ha bisogno di numeri di sequenza e di uno snapshot a ogni riconnessione.
Le dashboard live mantengono connessioni a lunga durata aperte, quindi piccoli errori di auth possono perdurare per minuti o ore. La sicurezza riguarda meno il trasporto e più come autentichi, autorizzi ed espi la sessione.
Parti dalle basi: usa HTTPS e tratta ogni connessione come una sessione che deve scadere. Se ti affidi a cookie di sessione, assicurati che siano scopi correttamente e ruotati al login. Se usi token (come JWT), mantienili a breve durata e pianifica come il client li rinnova.
Una trappola pratica: il browser SSE (EventSource) non permette di impostare header custom. Questo spesso spinge i team verso l'auth via cookie, o a mettere un token nell'URL. I token in URL possono trapelare tramite log e copia/incolla, quindi se devi usarli, rendili a breve durata ed evita di loggare query string complete. WebSockets tipicamente danno più flessibilità: puoi autenticare durante l'handshake (cookie o query string) o subito dopo la connessione con un messaggio di auth.
Per dashboard multi-tenant, autorizza due volte: alla connessione e a ogni subscribe. Un utente dovrebbe poter sottoscrivere solo stream che possiede (per esempio, org_id=123), e il server dovrebbe farlo rispettare anche se il client chiede di più.
Per ridurre gli abusi, limita e monitora l'uso delle connessioni:
Quei log sono la tua traccia di audit e il modo più veloce per spiegare perché qualcuno ha visto una dashboard vuota o i dati di qualcun altro.
Inizia con una domanda: la tua dashboard guarda per lo più, o parla anche molto? Se il browser riceve principalmente aggiornamenti (grafici, contatori, spie) e le azioni utente sono occasionali (cambio filtro, ack di un avviso), mantieni il canale real-time monodirezionale.
Poi guarda a 6 mesi: se prevedi molte funzionalità interattive (modifiche inline, controlli stile chat, drag-and-drop) e molti tipi di evento, pianifica un canale che gestisca bene entrambe le direzioni.
Decidi quanto corretta deve essere la vista. Se puoi perdere qualche aggiornamento intermedio (perché il prossimo aggiornamento sovrascrive lo stato), puoi favorire la semplicità. Se hai bisogno di replay esatto (ogni evento conta, audit, tick finanziari), ti servono sequenze robuste, buffering e logica di re-sync qualunque sia il trasporto.
Infine, stima concorrency e crescita. Migliaia di spettatori passivi di solito ti spingono verso l'opzione che gioca bene con l'infrastruttura HTTP e la scalabilità orizzontale semplice.
Scegli SSE quando:
Scegli WebSockets quando:
Se sei indeciso, scegli SSE per prima per dashboard tipicamente read‑heavy e passa solo quando le necessità bidirezionali diventano reali e costanti.
Il fallimento più comune inizia scegliendo uno strumento più complesso di quanto serva. Se l'UI ha solo bisogno di aggiornamenti server->client (prezzi, contatori, stato job), WebSockets possono aggiungere parti mobili in più con poco valore. I team finiscono a debuggare lo stato della connessione e l'instradamento dei messaggi invece della dashboard.
La reconnessione è un'altra trappola. Una reconnessione di solito ripristina la connessione, non i dati mancanti. Se il laptop di un utente va in sleep per 30 secondi, può perdere eventi e la dashboard mostra totali errati a meno che tu non progetti un passo di catch-up (per esempio: last seen event id o timestamp, poi refetch).
Broadcasting ad alta frequenza può silenziosamente portarti giù. Inviare ogni piccolo cambiamento (ogni update di riga, ogni tick CPU) aumenta carico, chatter di rete e jitter nell'UI. Batching e throttling spesso rendono la dashboard più veloce perché gli aggiornamenti arrivano in blocchi puliti.
Occhio a questi gotcha di produzione:
Esempio: una dashboard del support mostra conteggi ticket live. Se spingi ogni cambio di ticket istantaneamente, gli agenti vedono numeri sfarfallare e a volte tornare indietro dopo la reconnessione. Un approccio migliore è inviare aggiornamenti ogni 1-2 secondi e, alla reconnessione, recuperare i totali correnti prima di riprendere gli eventi.
Immagina una dashboard admin SaaS che mostra metriche di fatturazione (nuove sottoscrizioni, churn, MRR) più avvisi di incidente (errori API, backlog di code). La maggior parte degli spettatori guarda solo i numeri e vuole che si aggiornino senza ricaricare la pagina. Solo pochi admin eseguono azioni.
All'inizio, parti con lo stream più semplice che soddisfa il bisogno. SSE è spesso sufficiente: push di metriche e messaggi di allerta in una direzione dal server al browser. C'è meno stato da gestire, meno casi limite e il comportamento di reconnessione è prevedibile. Se manca un aggiornamento, il prossimo messaggio può includere i totali aggiornati così l'UI si auto‑ripara rapidamente.
Dopo qualche mese, l'uso cresce e la dashboard diventa interattiva. Ora gli admin vogliono filtri live (cambiare finestra temporale, toggle regioni) e magari collaborazione (due admin che ackano lo stesso avviso e lo vedono aggiornarsi all'istante). Qui la scelta può invertirsi. La messaggistica bidirezionale rende più facile inviare azioni utente sullo stesso canale e mantenere lo stato UI condiviso sincronizzato.
Se devi migrare, fallo in modo sicuro invece di cambiare tutto in una notte:
Prima di mettere una dashboard live davanti a utenti reali, assumi che la rete sarà instabile e alcuni client saranno lenti.
Dai a ogni aggiornamento un ID evento unico e un timestamp, e scrivi la tua regola di ordinamento. Se due aggiornamenti arrivano fuori ordine, quale vince? Questo conta quando una reconnessione rigioca eventi più vecchi o quando più servizi pubblicano aggiornamenti.
La reconnessione deve essere automatica e educata. Usa backoff (veloce all'inizio, poi più lento) e smetti di riprovare per sempre quando l'utente effettua il logout.
Decidi anche cosa fa l'UI quando i dati sono stale. Per esempio: se non arrivano aggiornamenti per 30 secondi, desatura i grafici, metti in pausa le animazioni e mostra uno stato chiaro "stale" invece di mostrare silenziosamente numeri vecchi.
Imposta limiti per utente (connessioni, messaggi al minuto, dimensione payload) così una tempesta di tab non manda giù tutti. Traccia la memoria per connessione e gestisci i client lenti. Se un browser non riesce a tenere il passo, non lasciare le code crescere illimitate. Chiudi la connessione, invia aggiornamenti più piccoli o passa a snapshot periodici.
Logga connect, disconnect, reconnect e ragioni di errore. Allerta su picchi insoliti di connessioni aperte, rate di reconnessione e backlog messaggi.
Tieni un interruttore di emergenza semplice per disabilitare lo streaming e tornare al polling o al refresh manuale. Quando qualcosa va storto alle 2 di notte, vuoi un'opzione sicura.
Mostra "Last updated" vicino ai numeri chiave e includi un pulsante di refresh manuale. Riduce i ticket di supporto e aiuta gli utenti a fidarsi di quello che vedono.
Parti piccolo di proposito. Scegli un solo stream prima (per esempio CPU e request rate, o solo avvisi) e definisci il contratto evento: nome evento, campi, unità e frequenza. Un contratto chiaro evita che UI e backend scivolino.
Costruisci un prototipo usa-e-getta che si concentri sul comportamento, non sulla rifinitura. Fai vedere all'UI tre stati: connecting, live e catching up dopo la reconnessione. Poi forza i failure: chiudi la tab, attiva la modalità aereo, riavvia il server e osserva cosa fa la dashboard.
Prima di scalare il traffico, decidi come recupererai i gap. Un approccio semplice è inviare uno snapshot alla connessione (o riconnessione), poi tornare agli aggiornamenti live.
Passi pratici prima di un rollout più ampio:
Se vai veloce, Koder.ai (koder.ai) può aiutarti a prototipare l'intero ciclo rapidamente: una UI React, un backend Go e il flusso dati costruito da un prompt chat, con esportazione del codice sorgente e opzioni di deploy quando sei pronto.
Quando il prototipo sopravvive a condizioni di rete brutte, scalare è per lo più ripetizione: aggiungi capacità, misura la latenza e mantieni noioso e affidabile il percorso di reconnessione.
SSE quando il browser ascolta principalmente e il server trasmette. È adatto a metriche, avvisi, spie di stato e pannelli "ultimi eventi" dove le azioni utente sono occasionali e possono passare tramite normali richieste HTTP.
Scegli WebSockets quando la dashboard è anche un pannello di controllo e il client deve inviare azioni frequenti e a bassa latenza. Se gli utenti inviano costantemente comandi, ack, modifiche collaborative o altri input real-time, la messaggistica bidirezionale è solitamente più semplice da gestire con WebSockets.
SSE è una risposta HTTP a lunga durata dove il server spinge eventi al browser. WebSockets effettuano l'upgrade della connessione a un protocollo bidirezionale separato così entrambe le parti possono inviare messaggi in qualsiasi momento. Per dashboard ad uso prevalentemente in lettura, la flessibilità bidirezionale spesso è un overhead non necessario.
Aggiungi un ID evento (o un numero di sequenza) a ogni aggiornamento e definisci un chiaro percorso di "recupero". Alla riconnessione il client dovrebbe o rigiocare gli eventi mancanti (quando possibile) o richiedere uno snapshot aggiornato dello stato corrente, poi riprendere gli aggiornamenti live in modo che l'interfaccia torni corretta.
Considera la staleness come uno stato UI reale, non un errore nascosto. Mostra qualcosa tipo "Last updated" vicino ai numeri chiave e se non arrivano eventi per un po', marca la vista come stale in modo che gli utenti non si fidino involontariamente di dati obsoleti.
Inizia limitando la quantità di dati inviati e evitando di trasmettere ogni piccolo cambiamento. Coalesci gli aggiornamenti frequenti (invia l'ultimo valore invece di ogni valore intermedio) e preferisci snapshot periodici per i totali. Il principale problema di scalabilità sono spesso le connessioni aperte e i client lenti, non la banda grezza.
Un client lento può far crescere i buffer sul server e consumare memoria per connessione. Limita la coda di dati per client, scarta o rallenta gli aggiornamenti quando un client non riesce a tenere il passo, e preferisci messaggi di stato "ultimo valore" invece di accuмuli lunghi per mantenere il sistema stabile.
Autentica e autorizza ogni stream come una sessione che deve scadere. SSE nei browser tipicamente orienta verso l'autenticazione via cookie perché non si possono impostare header custom su EventSource; WebSockets richiedono invece tipicamente un handshake o un primo messaggio di auth. In ogni caso, fai rispettare permessi per tenant e stream sul server, non solo nell'UI.
Manda eventi piccoli e frequenti sul canale live e riserva il lavoro pesante alle normali richieste HTTP. Caricamento iniziale della pagina, query storiche, esportazioni e risposte grandi sono meglio come richieste normali; lo stream live dovrebbe trasportare aggiornamenti leggeri che mantengono l'interfaccia aggiornata.
Esegui entrambi i canali in parallelo per un po' e duplica gli stessi eventi in ciascuno. Sposta una piccola percentuale di utenti per volta, testa riconnessioni e riavvii del server in condizioni realistiche, poi taglia gradualmente. Tenere il percorso vecchio come fallback rende i rollout molto più sicuri.