Un push push può contenere dati o fare in modo che il ricevitore attivi una chiamata API?

Question

Un push push può contenere dati o fare in modo che il ricevitore attivi una chiamata API?

#1 da (4 voti)

3

Con WebSockets, quando i client devono essere informati che i dati sono cambiati, ho visto due approcci:

il server invia le modifiche ai dati direttamente all'interno della push;
o il server non invia dati e il client, al ricevimento, attiva una chiamata API per ottenere i dati aggiornati.

Quale useresti e in tal caso?

Nel mio caso, il server fa un bel po 'di calcoli prima di servire i dati attraverso gli endpoint HTTP (cioè è non solo "serializzare questa tabella di database"), quindi penso che opterò per primo approccio, in modo che questi calcoli non debbano essere eseguiti sia lato client che lato server.

Ma sarei felice di avere le tue opinioni su questo prima di procedere.

api http web websockets push

posta sp00m 19.09.2017 - 15:51

fonte

1 risposta

Leggi altre domande sui tag api http web websockets push

Un DAO può impostare l'ID e restituire l'istanza nelle operazioni Salva / Aggiorna? Qual è la relazione tra promesse e continuazioni

score 4 · Accepted Answer

Le seguenti domande possono influenzare la tua scelta:

per quanto tempo il server deve calcolare il risultato?
è il risultato di una richiesta unica o è trasmesso a più richiedenti?
quanto è grande il dato (carico utile) da spingere?
i clienti sono sempre interessati a tutti i risultati spinti?
alcuni risultati potrebbero andare persi o i dati devono sempre essere consegnati?
è possibile che i client abbiano connessioni lente o problemi di qualità della connessione?

In base a questi aspetti, puoi optare per un push di dati se:

le connessioni sono affidabili
o se i dati non sono troppo grandi
o se il cliente è sempre interessato ai risultati
o se i risultati devono essere aggiornati frequentemente
o se i risultati sono necessari il più possibile in tempo reale

Potresti essere interessato a una notifica push o in Server-Sent-Events (SSE) in tutti gli altri casi, e ad esempio per far fronte a:

ricollega (con SSE) e applicazioni client chiuse
problemi di qualità della rete durante la trasmissione di grandi insiemi di dati che renderebbero posticipata la trasmissione un'alternativa più piacevole (o prendere in considerazione enormi costi di roaming quando si utilizza un telefono cellulare all'estero ...)
ignora i risultati obsoleti
se i vincoli sul lato server non consentono il full-duplex o richiedono di andare oltre http

Si noti tuttavia che SSE non è altrettanto valido supportato dai browser come websocket, sicuramente rendendo la successiva la scelta più facile.