Un pattern che vedo spesso nella revisione di applicazioni web moderne:
Server > WebSocket > "Ehi, ci sono 3 nuovi eventi!"
Client > HTTP GET > "Ok, dammi questi eventi"
Server > HTTP Response > [eventi]Il problema? Stiamo usando WebSocket come sistema di notifica, non come un efficiente canale di dati.
Cosa succede realmente
Il nostro socket ci dice: { "nuoviEventi": 2, "eventiModificati": 1 }, invia quindi un messaggio minimale. E il client risponde con un fetch HTTP per recuperare i dati effettivi.
Il risultato di questo approccio è questo:
- 1 messaggio WebSocket (inutilmente scarno/privo di informazioni)
- 1 richiesta HTTP completa con relativo overhead di headers
- 1 risposta HTTP
Le conseguenze sono una latenza aggiuntiva ed immediata ad ogni aggiornamento ed un carico extra sul server che scala in modo significativo ed esponenziale, all'aumentare dei client connessi (con 100 client connessi ad esempio, che ricevono tutti la stessa notifica, il server gestisce 100 richieste HTTP che potevano non esistere).
Soluzione
La soluzione è semplice: mandare i dati direttamente nel WebSocket. L'approccio corretto è il seguente:
{
"tipo": "sync",
"nuovi": [{ "id": 1, "titolo": "Riunione", ... }],
"modificati": [{ "id": 5, "titolo": "Updated", ... }],
"eliminati": [12, 15]
}Un solo messaggio. Zero fetch. Aggiornamento istantaneo.
E questo è il giusto modo di gestire gli aggiornamenti, fatta eccezione di casi limite in cui il fetch può avere ancora un senso, come: payload enormi, dati che richiedono paginazione, richieste on-demand dell'utente. Ma per la sincronizzazione real-time di entità di dimensioni standard, il canale bidirezionale esiste già ed è già lì. Bisogna solo approfondirne il funzionamento ed utilizzarlo, con intelligenza, per quello che è.