WebSockets rispetto alla chiamata Ajax per l'evento pianificato?

Non vedrai un'enorme differenza.

Bene, il sondaggio consumerà molta più larghezza di banda semplicemente dalle intestazioni delle richieste a meno che non si utilizzino tecniche come il polling lungo, in cui il server non risponde alle richieste immediatamente ma attende fino a quando non sono disponibili nuovi dati o scade un certo timeout ( nel qual caso il cliente inizia la richiesta successiva). Ciò consente aggiornamenti istantanei, proprio come Websockets.

La differenza è che i websocket possono inviare più messaggi in entrambe le direzioni utilizzando la stessa connessione, mentre con il polling lungo il server può fornire solo una risposta per connessione. Connessione qui significa richiesta HTTP, anche se le connessioni TCP e TLS sottostanti potrebbero essere riutilizzate. Il polling lungo è di poco conto se il tuo server web si basa su un loop di eventi, ma è problematico nei server web a thread singolo per richiesta.

Ma a parte questo, non c'è davvero un'enorme differenza. In entrambi i casi, il server dovrà gestire un numero elevato di connessioni aperte simultanee. Nel caso di polling senza polling lungo, avrai meno connessioni simultanee ma impiegheresti più tempo a rispondere a tutte le richieste, il che comunque non sarà molto se gli eventi possono essere memorizzati nella cache.

È probabile che la cache sia una normale struttura di dati in memoria che persiste tra le richieste. Non deve essere un server cache esterno.

Quindi, crea semplicemente la cosa più semplice che funzioni per te. Sia Java che C # hanno un ecosistema di librerie molto maturo, quindi è probabile che siano disponibili buone implementazioni. Quando c'è un problema, considera il refactoring per usare una soluzione più elaborata e più performante. La mia ipotesi è che il polling lungo andrà bene, a meno che i client in genere ricevano più messaggi al minuto, oa meno che non si abbiano più connessioni di quelle che il tuo server web principale può gestire comodamente.

È passato un po 'di tempo da quando ho giocato con i websockets (server: java) e averli sistemati e lavorato non era poi così difficile. Le sfide che ho avuto noi più sul lato client. Tornerò su questo. Non dovresti aver bisogno di un server aggiuntivo. Puoi aggiungerlo in un server web esistente.

Websockets sembrerebbe essere una buona idea qui, ma se probabilmente introdurrebbe qualche nuovo problema. Una cosa che non capisco è che se stai usando websockets, perché sondare sul server? Sarebbe più sensato che l'API pubblicasse eventi che sarebbero poi tradotti in chiamate websocket.

Eviterei di provare a inviare il payload dei dati attraverso il websocket. Invece emetti un piccolo messaggio che dice al client che c'è qualcosa da ottenere dal server. La ragione per cui dico questo ha a che fare con le sfide sul cliente. Per prima cosa, non dovresti costruire questo intorno all'idea che il cliente sarà sempre attivo e in ascolto. Se qualcuno chiude il proprio browser o chiude il proprio laptop, non lo ascolta. La prima cosa che il cliente deve fare è essere in grado di ottenere lo stato attuale delle cose e / o gli eventi che sono stati persi. Fai questo con normali chiamate Ajax.

Ora che hai il modo in cui il cliente si può raddrizzare, la prossima sfida è mantenere il client connesso. Quello che vidi quando lavoravo con le web socket era che non sarebbero rimasti aperti a tempo indeterminato. È necessario avere una sorta di procedura di ri-connessione sul client che coinvolgerà di nuovo rimanere intrappolati.

Un'alternativa qui sarebbe quella di aggiungere un'ultima modifica alle intestazioni sulla risposta ajax. Quindi puoi utilizzare la logica If-Modifed-Since o creare HEAD chiamate per verificare gli aggiornamenti in base a ETag o Last-Modified senza dover scaricare il payload ogni volta. C'è ancora un sacco di chattiness però.