Ajax vs Socket.io

Question

Sto sviluppando un'applicazione web e mi chiedevo quale metodo dovrebbe essere adatto al mio progetto.

In pratica, quello che voglio mostrare agli utenti sono alcune notifiche che vengono prese dalle richieste ad altri server. La mia app node.js riceve tutte le informazioni e quindi si estende agli utenti, salvando una copia nel mio MongoDB.

L'idea è abbastanza semplice ma leggendo sui metodi ho trovato queste due tecniche:

1. Ajax: lato client sarebbe il controllo di tutti i tempi se c'è nuovi contenuti sul server. Ciò avverrebbe utilizzando jquery ajax per accedere all'API del server (ogni 30/60 secondi).

2. Socket.io: il client si connette una volta e quindi viene mantenuta una connessione TCP permanente (più tempo reale).

---

ora ho spiegato la situazione, ho le seguenti domande:

• Non avrei troppe richieste con l'Ajax? Immagina di voler controllare ogni minuto il server, se scaliamo l'app a 100 utenti, mi daranno 100 query al minuto. Sarebbe "più economico" nelle risorse di sistema avere un socket?

• Il socket.io sarebbe un problema per i dispositivi mobili? bandwith e prestazioni. La risposta del server è sempre informazioni in formato JSON.

• Ho letto che now.js potrebbe essere utilizzato per questo ma sembra che il progetto non sia più supportato, quindi non è sicuro se utilizzarlo sarebbe una buona idea.

• Come si memorizza la cache su entrambi i metodi? Stavo considerando di creare un file di cache per ogni utente e questo sarebbe aggiornato dal nodo.js sul lato server. Immagino che questo potrebbe funzionare molto bene con ajax ma per quanto riguarda socket.io?

• È vero che socket.io non è affatto compatibile con molti browser? La mia app sarebbe più focalizzata sui dispositivi mobili e penso che questo potrebbe farmi pensare a scegliere ajax.

• Qual è l'alternativa suggerita?

Spero che questo potrebbe cancellare la mia mente e gli altri che sono nella stessa situazione :) Grazie

Answer 1

Molti dei compromessi tra generici websocket e Ajax sono discussi qui:

websocket vs rest API for real time data?

Alcuni problemi di tradeoff per i dispositivi mobili sono discussi qui:

Cordova: Sockets, PushNotifications, or repeatedly polling server?

In breve, se i dati sono principalmente basati su server e quindi devono essere inviati ai client e si desidera una latenza abbastanza buona per quando i client vedono i nuovi dati, allora questo è il problema esatto che webSockets sono buoni per.webSockets funziona meglio in questa situazione perché il client non ha bisogno di eseguire il polling frequentemente, il server non ha bisogno di gestire richieste di polling regolari da molti client. Invece, ogni client imposta semplicemente il canale di comunicazione persistente webSocket che il server può quindi inviare i dati in base alla richiesta in qualsiasi momento.

Non avrei troppe richieste con ajax? immagina che voglio un assegno ogni minuto al server, se scaliamo l'app a 100 utenti, sarà darmi 100 query al minuto. Sarebbe "più economico" nelle risorse del sistema avere un socket?

I socket richiedono pochissime risorse quando non sono attivi, quindi sì, un webstack peristente è più efficiente di molti client che interrogano all'infinito. Questo è il motivo per cui i web-socket sono stati inventati perché sono più adatti a risolvere questo particolare problema.

Il socket.io potrebbe essere un problema per i dispositivi mobili? banda larga e prestazioni . La risposta del server è sempre informazioni in formato JSON.

socket.io non è un problema per larghezza di banda o prestazioni. Ci sono alcuni problemi con i dispositivi mobili nel cercare di utilizzare webSockets in background perché i dispositivi mobili stanno anche tentando di eseguire la gestione attiva dell'alimentazione, anche se esiste un problema simile anche con il polling dei client.

Come si memorizza la cache su entrambi i metodi? Stavo considerando di creare un file di cache per ogni utente e questo sarebbe aggiornato dal nodo.js in lato server. Immagino che questo potrebbe funzionare molto bene con ajax ma e su socket.io?

Non è chiaro cosa stai chiedendo sulla memorizzazione nella cache? In un'implementazione webSocket, il server riceve i dati e quindi li invia a ciascun utente. Generalmente non è necessaria la memorizzazione nella cache sul lato server. In un'implementazione di polling client Ajax, il server dovrebbe memorizzare i dati da qualche parte e "attendere" che ciascun client richieda i dati. Non esiste un meccanismo di caching "integrato" per webSocket o Ajax.

È vero che socket.io non è affatto compatibile con molti browser ? La mia app sarebbe più focalizzata sui dispositivi mobili e penso che questo potrebbe farmi pensare invece di scegliere ajax.

socket.io è completamente compatibile con tutti i browser che hanno webSocket che è praticamente tutto in uso oggi tranne IE9 e precedenti. Se si utilizza la libreria socket.io, verrà automaticamente eseguito il polling lungo se i webSocket non esistono. È probabile che i problemi relativi ai dispositivi mobili siano simili se esegui polling regolari o webSocket, in quanto il dispositivo mobile desidera alimentare la gestione di attività a esecuzione prolungata, ma non vuoi interrompere il polling. Non penso che questo sia un motivo per evitare webSockets/socket.io. socket.io ha una buona logica di riconnessione automatica ogni volta che perde la connessione che può essere davvero utile.

Nel mondo mobile, penso che scoprirai che non puoi fare in modo affidabile notifiche in tempo reale in background senza utilizzare una sorta di componente nativo dell'app che può essere collegato al sistema "push" nativo sul dispositivo perché questo è l'unico sistema che è al tempo stesso batteria efficiente e pienamente compatibile con il risparmio energetico. Una pagina Web verrà gestita automaticamente non appena non è l'attività in primo piano o quando il dispositivo è rimasto inattivo.