2012-08-16 8 views
14

Sto costruendo un'applicazione Web utilizzando Firebase che acquisisce gli stessi dati e li presenta in due modi diversi: in un elenco e come marker su una mappa di google.Firebase: il caching migliora le prestazioni?

In questo momento, in ogni vista, mappa o elenco, ho il codice per interrogare i dati da Firebase, unirli e visualizzarli. Invece, sto prendendo in considerazione questo piano: all'avvio, interrogare i dati, unirli e salvarli tutti in una matrice che passo dalla vista alla vista.

In un certo senso, sto "memorizzando nella cache" i dati del firebase in una matrice. Questo non è l'ideale in un senso: i dati memorizzati nella cache non sono aggiornati quanto direttamente interrogando Firebase. D'altra parte, chiamo Firebase solo una volta.

Questo ha senso per le prestazioni? La lettura dei dati da un Firebase avviene nello stesso ordine di grandezza dei dati di lettura di un array?

risposta

21

In generale, i dati di memorizzazione nella cache per limitare l'utilizzo di Firebase non sono necessari. Firebase mantiene la propria cache di dati "attivi" sul client. "Attivo" è definito come dati per i quali è in attesa una chiamata "on". Pertanto, per qualsiasi dato attivo, qualsiasi chiamata "on" o "una volta" aggiuntiva non richiederà traffico di rete poiché i dati sono già stati caricati.

Non sono del tutto sicuro di cosa intendi con "query al firebase". Firebase non ha query nel senso tradizionale. Ha semplicemente i metodi per allegare i callback. Stai utilizzando la funzione "una volta()" per ottenere periodicamente dei dati da Firebase? Se così fosse, questo potrebbe potenzialmente essere molto inefficiente. Una volta è un metodo di convenienza e generalmente dovrebbe essere utilizzato solo per i dati a cui si accede raramente o che per qualche motivo lo sviluppatore non vuole aggiornarsi in tempo reale. Se nessuna chiamata "on" attiva è in sospeso quando una volta() viene completata, Firebase svuota la cache di tali dati e qualsiasi chiamata successiva a once() richiederà un roundtrip al server.

Se quello che vuoi è un modo per accedere in modo sincrono una copia locale della versione più recente dei dati in modo efficiente, vi consiglio questo metodo:

var savedSnapshot = null; 
dataRef.on("value", function(snapshot) { 
    savedSnapshot = snapshot; 
}); 

//and then when you need to read the data 
var theData = savedSnapshot.val() 

Mantenendo un singolo() chiamata, Firebase è in grado di mantenere i tuoi dati aggiornati semplicemente inviando delta via cavo quando le cose cambiano, piuttosto che ricaricare tutti i dati ogni volta che ne hai bisogno.

+1

Grande spiegazione. I documenti, btw, danno questa impressione ma non entrano in un dettaglio così grande (questa potrebbe essere una grande appendice ai documenti) – Kato

+1

Stiamo pianificando di aggiungere alcune sezioni sulle prestazioni ai documenti nel prossimo futuro. –

+0

@AndrewLee questa sezione delle prestazioni verrà mai scritta? Sto usando Firebase da 2 anni e non ho "cliccato" esattamente come ha fatto quando questa (5 anni) risposta ha spiegato come è possibile memorizzare un datasnapshot in giro per un utilizzo successivo. Ora mi rendo conto che ho codificato difensivamente molto, per paura di non sapere cosa fa Firebase e non "memorizza" internamente. Ora vedo che DataSnapshot è solo un cursore navigabile verso una struttura interna immutabile e che 'val()' clona i suoi dati in un POJO. Questo è così elegantemente progettato! Giù i cappelli :-) – skrebbel

Problemi correlati