Utilizzo di raccolte Backbone di grandi dimensioni

Question

Stiamo progettando un'applicazione backbone in cui ogni raccolta lato server può contenere decine di migliaia di record. Per analogia, pensa di entrare nella vista "Posta inviata" di un'applicazione di posta elettronica.

Nella maggior parte degli esempi di Backbone che ho visto, le raccolte coinvolte sono al massimo 100-200 record, e quindi il recupero dell'intera collezione e il lavoro con esso nel client è relativamente facile. Non credo che questo sarebbe il caso con un set molto più grande.

qualcuno ha fatto un lavoro con Backbone sulle collezioni lato server di grandi dimensioni?

• Si sono verificati problemi di prestazioni (soprattutto su dispositivi mobili) a una determinata dimensione di raccolta?
• Quali decisioni ha preso in giro quanto prelevare dal server?
• Scarichi tutto o solo un sottoinsieme?
• Dove si fa a mettere la logica intorno a qualsiasi meccanismo personalizzato (Collection prototipo per esempio?)

Answer 1

1. Sì, a circa 10.000 articoli, browser più vecchi non potevano gestire bene il display. Abbiamo pensato che si trattasse di un problema di larghezza di banda, ma anche a livello locale, con la stessa larghezza di banda che una macchina ad alte prestazioni poteva lanciare, Javascript è semplicemente svenuto. Questo era vero su Firefox 2 e IE7; Da allora non l'ho testato su sistemi più grandi.

2. Stavamo cercando di recuperare tutto. Questo non ha funzionato per dataset di grandi dimensioni. Era particolarmente pernicioso con il browser di Android.

3. I nostri dati si trovavano in una struttura ad albero, con altri dati a seconda della presenza di dati nella struttura ad albero. I dati potrebbero cambiare a causa di azioni di altri utenti o di altre parti del programma. Alla fine, abbiamo reso la struttura ad albero solo i nodi attualmente visibili, e le altre parti del sistema hanno verificato la validità dei set di dati su cui dipendono in modo indipendente. Questa è una condizione di gara, ma nella distribuzione effettiva non abbiamo mai visto alcun problema. Mi sarebbe piaciuto usare socket.io qui, ma la direzione non capiva o non si fidava di esso.

4. Da quando utilizzo Coffeescript, ho ereditato da Backbone.Collection e creato la mia superclasse, che ha anche istanziato una chiamata personalizzata sync(). La sintassi per invocare il metodo di una superclasse è veramente utile qui:

   class Dataset extends BaseAccessClass 
       initialize: (attributes, options) -> 
        Dataset.__super__.initialize.apply(@, arguments) 
        # Customizations go here. 
   

Answer 2

Come Elf detto si dovrebbe davvero impaginare il caricamento dei dati dal server. Si risparmia molto carico sul server dal download di elementi che potrebbero non essere necessari. La creazione di una raccolta con modelli 10k in locale in Chrome richiede mezzo secondo. È un carico enorme.

È possibile mettere il lavoro su un altro thread CPU fisica utilizzando un lavoratore e quindi utilizzare gli oggetti transitori per inviato al thread principale al fine di renderla sul DOM.

Una volta che una raccolta di quel grande rendering nel rendering pigro del DOM ti porterà solo lontano. La memoria aumenterà lentamente fino a quando non si blocca il browser (che sarà veloce su tablet). È necessario utilizzare il pool di oggetti sugli elementi. Ti permetterà di impostare una dimensione massima piccola per la memoria e di tenerla lì.

Sto costruendo un PerfView for Backbone in grado di eseguire il rendering di 1.000.000 di modelli e di scorrere a 120 FPS su Chrome. Il codice è tutto su Github https://github.com/puppybits/BackboneJS-PerfView. Ha commentato così ci sono molte altre ottimizzazioni necessarie per visualizzare grandi serie di dati.