Come funzionano le app di Meteor offline?

Questo è utile quando:

  • il server è inattivo e il client non può connettersi per la sincronizzazione in tempo reale
  • non c’è connettività Internet
  • l’utente non vuole andare online ma vuole lavorare con l’applicazione;

Sì! Questo è già implementato in Meteor, per la maggior parte.

Se la connessione al server è persa, il client può ancora funzionare localmente. Le scritture del database sembreranno avere successo sul client e riflettere istantaneamente sullo schermo. Una volta ristabilita la connessione, Meteor invierà nuovamente tutte le richieste di metodo in sospeso al server e aggiornerà la visualizzazione del client con i risultati del server. Questo è tutto il risultato della compensazione della latenza, essendo offline viene trattato come se il server fosse molto lento.

I client possono monitorare l’uscita retriggers ‘Meteor.status ()’ per vedere lo stato della connessione corrente. Ad esempio potresti usare Meteor.status per guidare un popup con un timer di riconnessione e un pulsante ‘connetti ora’, come gmail.

EDIT: ovviamente, Meteor non è magico. Se clicchi su ‘ricarica’ o navighi lontano dalla pagina, ecc. Mentre offline perderai la tua sessione di Meteor e non potrai ricominciare da capo finché non riacquisti la rete. Questo è vero per tutte le app Web con modalità offline, quindi non dovrebbe essere una sorpresa per gli utenti della tua app.

C’è un altro paio di opzioni che potrebbero risolvere il problema “se la scheda si chiude o si ricarica”. Non li ho ancora provati ma sembrano interessanti.

https://github.com/awwx/meteor-offline-data :

Meteor Offline Data

Home del progetto di dati offline di Meteor, implementando una “Collezione offline” che avvolge un Meteor.Collection:

I dati dal server sono memorizzati in modo persistente nel database del browser, rendendolo disponibile all’applicazione anche se l’applicazione si avvia offline.

Le modifiche apportate dall’utente vengono inoltre salvate nel database del browser, conservandole se il browser viene chiuso e riaperto. La prossima volta che l’applicazione passa online, le modifiche vengono inviate al server.

Gli aggiornamenti vengono condivisi in modo reattivo tra le windows del browser aperte sulla stessa applicazione, anche offline.

e https://github.com/GroundMeteor/Meteor-GroundDB :

Caratteristiche:

Impronta leggera

Ampio supporto per browser Chrome, Safari, Firefox e Internet Explorer 9 Fallback to normal Meteor.Collection in assenza di memoria locale Ripresa delle modifiche nelle raccolte Ripresa dei metodi Funziona offline aggiornando le windows della finestra Supporto per SmartCollection Supporto per database offline solo lato client Utilizza EJSON.minify e EJSON.maxify per comprimere i dati in localstorage In futuro ci sarà un gestore di conflitti personalizzabile sul lato server

In basso della linea:

1) O il browser può salvare completamente la sessione effettiva (ogni quanto? Ogni volta che l’app lo richiede perché ha delle modifiche. Per tale app, ogni 10 secondi non è sufficiente, abbiamo bisogno di ogni evento). Possiamo programmarlo, diciamo, Firefox? (Ma sarebbe necessario salvare tutto (HTML, JS, MinoMongoDB, ecc. Solo per una modifica!)

2) Oppure abbiamo una pila di meteore completa lato client che si occupa di cose locali (un’app locale propria) ma in qualche modo comunica le sue operazioni CRUD a un’altra app online in un’altra scheda o istanza del browser. (Quella seconda app sarebbe servita dal vero server remoto) Il problema è se queste 2 app possono comunicare. Suppongo che i browser lo vieterebbero per motivi di sicurezza)

Un’altra idea più creativa potrebbe essere: triggersre l’oplog sullo stack del client. Quindi, ogni back-online e costantemente on-line, l’oplog del client effettivo potrebbe essere esportato / importato nell’app principale (che è un altro log di oplog),

3) A meno che non possiamo inviare una richiesta call () dallo stack completo meteor del cliente a un altro stack di meteora sul server. (È ansible? Ci sono alcune regole sui limiti del dominio URL in meteor)

Ma non fissa la possibilità di avere una pila di meteore piena su un tablet (non sono a conoscenza di cosa è ansible fare shuch)

Non sono un esperto ma immaginiamo una soluzione:

Non su un tablet / cella (non siamo sicuri di poter installare una pila di meteoriti su tale dispositivo), ma sul desktop, l’utente ha bisogno di una disponibilità offline come il punto di vendita, qualche registrazione delle transazioni, un prodotto limitato o non aggiornato elenco, prezzi e inventario, ecc. (Le transazioni che utilizzano titoli che non sono fisicamente locali dovrebbero essere «da confermare (ordine offline)» (le sedi che hanno quel titolo potrebbero vendere anche se già prenotate da un ordine offline, che non sono a conoscenza di, perché loro o l’altro utente è offline, specialmente se l’utente che ha lo stock è quello offline)

Inoltre, alcune funzionalità potrebbero essere utilizzate solo online (utilizzando un’altra app Web di Meteor)

Ovviamente, non tutte le parti dell’applicazione possono essere utilizzate offline: creazioni di record sensibili, alcune transazioni, ricerche che richiedono la raccolta completa, ecc. Le funzionalità offline funzioneranno attraverso il server Web della macchina locale con un Meteor completo locale in pila già installato.

Oplog sincronizzerebbe questi DB offline con una raccolta di mirror sul server centralizzato, un DB specifico per utente, quindi non tutti i grandi dati disponibili offline sul computer dell’utente. L’idea è di mantenere la disponibilità di alcune funzionalità. Potremmo altrimenti disporre di un solo DB per le transazioni offline di tutti gli utenti, ma oplog sincronizzerebbe tutte queste transazioni su tutti i DB offline dell’utente. Potremmo pubblicare e cancellare questi record appena ansible, ma non per la privacy. Il migliore è il DB offline del client – e viene specchiato uno sul server centralizzato – includerebbe solo i record creati da quell’utente o le informazioni che l’utente potrebbe aver bisogno di un DB specifico per utente.

Una funzione lato server centrale convalida regolarmente e POST questi record al DB centralizzato inclusivo di tutti gli utenti.

Un modo semplice: tutte le transazioni eseguite con l’app meteo offline locale che registra le transazioni su un webservice quando disponibile. (in questo modo, gli utenti non devono gestire l’utilizzo di 2 applicazioni, andando avanti e indietro.)

Potremmo utilizzare un concetto di 2 numeri di fattura: numero di fattura di vendita: generato al momento della transazione (l’ID del documento?)

Numero di fattura sequenziale: a fini contabili, generato successivamente (quando online e per documenti da 15 a 20 secondi. Sappiamo con certezza tutte le nuove fatture che sono state create in quel periodo)

L’idea qui è di avere uno stack di meteora locale che si prende cura della persistenza locale, la sincronizzazione di Oplog con la persistenza centralizzata (a meno che non inviamo richieste di asincrone sul webservice per le transazioni che postano online, ma perdiamo l’auto sinc con il DB più grande)

(Dopotutto, forse è meglio avere 2 applicazioni in esecuzione: in locale, una centrale servita e un modo per far dialogare queste due persone, o un’app online e offline con un modo comodo per indirizzare l’utente a utilizzare quello online in priorità e quello offline se offline)

Sarebbe positivo se la comunità di persone più consapevoli valutasse e documentasse un modo di lavorare. Non ho ancora usato Meteor, ancora nel processo di apprendimento di base.

Grazie,

Marc