Push vs Poll quando è accettabile un ampio ritardo (ore)

Il polling è sempre accettabile quando il tempo reale non è una necessità. Quello che devi chiedertelo è perché dovresti usarne uno invece dell'altro?

Lo scopo di un servizio push è un paio di cose; può essere considerevolmente meno traffico da gestire se le tue trasmissioni sono trasmissioni e un fornitore di terze parti fa la trasmissione - questo ti consente di inviare un messaggio e di ricevere migliaia di persone. Ma come si nota, il più grande vantaggio di un servizio push è la natura in tempo reale che consente aggiornamenti immediati per raggiungere i vostri consumatori. Tuttavia, quando si fanno push, non si vuole mai spingere grandi set di dati se si sta trasmettendo, e si è anche in balia del servizio push di terze parti che si utilizza (se si utilizza uno).

Lo scopo di un sondaggio è controllare periodicamente le differenze di dati, in cui il periodo di aggiornamento può avere uno SLA accettabile di inesattezza fino a un certo periodo di tempo. Un sondaggio richiederà a tutti i clienti di richiedere periodicamente i dati, il che comporterà la richiesta di una connessione per ogni cliente in esecuzione e la necessità di un servizio dal vivo in grado di monitorare accuratamente tali dati per servirli fino ai poller. Avere dati accurati per servire significa una certa persistenza dei dati che occuperà il disco e i tempi di manutenzione.

Quindi da questo possiamo vedere che se hai dubbi sul traffico di rete o sulla manutenzione di un servizio (che significa possibilmente autenticare / autorizzare richieste, registrarle che occupano spazio su disco, tutti i normali requisiti di manutenzione di un servizio) allora non vuoi forzare i clienti a sondare. Tuttavia, se il caso d'uso richiede la trasmissione di un set di dati particolarmente ampio o non si può essere legati all'API di terze parti che possono cambiare nel tempo come pure il loro SLA o addebiti, è possibile che sia applicabile un sistema di polling domestico. spese generali possono essere significativamente più. In alternativa, potresti già eseguire il servizio e mantenere i dati in modo tale che il polling sia un'aggiunta leggera all'infrastruttura già esistente, il che rende il polling più desiderabile.

Anche se al punto centrale che ti fai essere corretto; se il tempo reale è necessario , il polling non funzionerà. Se non lo è, allora devi solo fare i calcoli su come periodici i dati possono essere controllati moltiplicati dalla base del tuo cliente moltiplicato per la dimensione del tuo set di dati per decidere se il costo della rete varrà la pena esso, o se un servizio push sarebbe meglio dove è sempre possibile semplicemente spingere un evento change che consente loro di richiedere il set di dati di grandi dimensioni in un passaggio secondario (anche se l'atomicità di questi passaggi potrebbe essere qualcosa che devi fare attenzione a seconda della criticità dei dati).

Il polling dovrebbe andare bene nel tuo caso. E non dovrai integrarti con un altro sistema (o più sistemi per più piattaforme).

Tuttavia, le specifiche dei dispositivi potrebbero essere un problema. Puoi eseguire il sondaggio in modo affidabile quando l'app non è anteriore e centrale sul dispositivo? (potrebbe o non potrebbe essere un problema per te). La tua capacità di farlo potrebbe dipendere dalla tecnologia che stai utilizzando per sviluppare l'app.

Naturalmente. È anche più semplice (fai attenzione ai picchi di tiro se tutti stanno seguendo lo stesso programma).

Detto questo, metterei in discussione l'ipotesi che "un ampio ritardo sia accettabile", considerando le aspettative degli utenti di dispositivi mobili. ('Le mappe non sono aggiornate in tempo reale! Non accettabile!' - oppure - 'So che è il servizio meteorologico, ma continuerò a spingere quel pulsante di aggiornamento ogni cinque secondi fino a quando le previsioni per domani diventeranno soleggiate!')