Le notifiche in tempo reale sono il luogo in cui i Websocket prosperano e offrono un enorme vantaggio rispetto ad AJAX.
Come sapete, questo è stato già discusso prima di entrambi durante il dibattito sul il ruolo di AJAX (ottimo per CRUD, non tanto durante i sondaggi) e quando si confronta Prestazioni Websocket e prestazioni AJAX (I WebSocket sono sempre più veloci per quanto riguarda gli aggiornamenti in tempo reale).
Sì... potresti risparmiare risorse e migliorare le prestazioni (oltre a futuri problemi di manutenzione del codice) aggiungendo on_update "aggancia" al punto di accesso al database.
L'idea è semplice:ogni volta che una chiamata di funzione aggiorna il database MySQL, anche la richiesta di aggiornamento viene inviata a un callback. Quella richiamata è responsabile della pubblicazione dell'aggiornamento sul canale corretto.
In questo modo, non esegui il polling del database MySQL.
Alcuni database offrono richiamate di aggiornamento e altri no. Penso che MySQL lo faccia. Tuttavia, evito questi callback collegati al database perché sono specifici del database. È meglio (IMHO) aggiungere la callback al punto di accesso del database nell'applicazione, in modo che la sostituzione di un database non influisca sulla base di codice.
Non credo che AJAX sia un buon approccio.
HTTP/2 aiuta a mitigare le carenze di AJAX, ma non le risolve tutte.
Non so quanti client ti aspetti siano connessi contemporaneamente, ma costringere un client a inviare una richiesta ogni secondo o due è molto simile a un attacco DoS autoinflitto.
Considera questo:se un client invia una richiesta AJAX ogni due secondi, rispetto a 2.000 client simultanei, il tuo server dovrà rispondere a 1.000 req/sec, inclusi autenticazione, query al database e tutto quel jazz.
D'altra parte, utilizzando Websocket, con 2.000 client connessi, hai 2.000 connessioni persistenti che non fanno nulla fino all'arrivo di un messaggio. Nessuna CPU o lavoro richiesto, solo la memoria della connessione. Non c'è stress sul server fino a quando non vengono inviati i dati effettivi.
Sì, sono più complessi da implementare, ma non sono così difficili una volta avviati. Inoltre, ci sono molte librerie e strumenti di supporto che ti alleggeriscono gran parte del lavoro.
I problemi comuni relativi all'approccio Websocket includono la gestione del ridimensionamento orizzontale (spesso aggiungendo un database o un servizio pub/sub, come Redis), l'ordinamento dei messaggi (che è meglio ignorare quando possibile) e i problemi di propagazione dei dati (quando contrassegniamo dati come "visti"? inviamo i dati completi o solo una notifica che indica che i dati sono disponibili? quanti canali utilizziamo e come dividiamo le iscrizioni?).
Di solito le risposte sono specifiche dell'applicazione e dipendono dalla funzionalità che stai cercando di svolgere, nonché dalle dimensioni previste del tuo set di dati (se ogni risposta che ho fornito su SO fosse un canale, non sarebbe realistico da mantenere).
Comunque... Buona fortuna!
