Quali sono le mie opzioni per l'archiviazione dei dati quando utilizzo React Native? (iOS e Android) [chiuso]

Sono ancora nuovo nel mondo dei React Native, e generalmente anche nel mondo mobile / nativo, e trovo che la documentazione sia un po 'carente quando si tratta della persistenza dei dati.

Quali sono le mie opzioni per l'archiviazione dei dati in React Native e le implicazioni di ciascun tipo? Ad esempio, vedo che esiste una memoria locale e una memoria asincrona, ma poi vedo anche cose come Realm e sono confuso su come tutto ciò funzionerebbe con un database esterno.

Voglio specificamente sapere:

• Quali sono le diverse opzioni per la persistenza dei dati?
• Per ciascuno, quali sono i limiti di tale persistenza (ovvero quando i dati non sono più disponibili)? Ad esempio: quando si chiude l'applicazione, si riavvia il telefono, ecc.
• Per ognuno, ci sono differenze (oltre alla configurazione generale) tra l'implementazione in iOS vs Android?
• Come si confrontano le opzioni per l'accesso ai dati offline? (o come viene gestito l'accesso offline?)
• Ci sono altre considerazioni che dovrei tenere a mente?

Grazie per l'aiuto!

Ecco cosa ho imparato mentre decido il modo migliore per andare avanti con un paio dei miei progetti di app attuali.

Async Storage ("integrato" per React Native)

Uso AsyncStorage per un'app in produzione. Lo spazio di archiviazione rimane locale sul dispositivo, non è crittografato (come indicato in un'altra risposta), scompare se si elimina l'app, ma deve essere salvato come parte dei backup del dispositivo e persiste durante gli aggiornamenti (entrambi gli aggiornamenti nativi ala TestFlight e gli aggiornamenti del codice tramite CodePush ).

Conclusione: archiviazione locale; fornisci la tua soluzione di sincronizzazione / backup.

SQLite

Altri progetti a cui ho lavorato hanno utilizzato sqlite3 per l'archiviazione delle app. Questo ti dà un'esperienza simile a SQL, con database comprimibili che possono anche essere trasmessi da e verso il dispositivo. Non ho avuto alcuna esperienza con la loro sincronizzazione con un back-end, ma immagino che esistano varie librerie. Esistono librerie RN per la connessione a SQLite.

I dati vengono archiviati nel tradizionale formato di database con database, tabelle, chiavi, indici, ecc., Tutti salvati su disco in un formato binario. L'accesso diretto ai dati è disponibile tramite riga di comando o app con driver SQLite.

Conclusione: archiviazione locale; fornisci la sincronizzazione e il backup.

Firebase

Firebase offre, tra le altre cose, un database noSQL in tempo reale insieme a un archivio di documenti JSON (come MongoDB) pensato per mantenere sincronizzati da 1 a n client. I documenti parlano della persistenza offline, ma solo per il codice nativo (Swift / Obj-C, Java). L'opzione JavaScript di Google ("Web") utilizzata da React Native non fornisce un'opzione di archiviazione memorizzata nella cache (vedere l'aggiornamento 2/18 di seguito). La libreria è scritta con il presupposto che un browser Web si connetterà e quindi ci sarà una connessione semi-persistente. Probabilmente potresti scrivere un meccanismo di memorizzazione nella cache locale per integrare le chiamate di archiviazione di Firebase, oppure potresti creare un ponte tra le librerie native e React Native.

Aggiornamento 2/2018 Da allora ho trovato React Native Firebase che fornisce un'interfaccia JavaScript compatibile alle librerie native iOS e Android (facendo ciò che Google probabilmente avrebbe potuto / avrebbe dovuto fare), dandoti tutte le chicche delle librerie native con il bonus di React Supporto nativo. Con l'introduzione di Google di un archivio di documenti JSON accanto al database in tempo reale, sto dando a Firebase una buona seconda occhiata ad alcune app in tempo reale che ho intenzione di costruire.

Il database in tempo reale è archiviato come un albero simile a JSON che è possibile modificare sul sito Web e importare / esportare in modo molto semplice.

Conclusione: con la reattiva-nativa-base di fuoco, RN ottiene gli stessi vantaggi di Swift e Java. [/ update] Si adatta bene ai dispositivi collegati in rete. Basso costo per basso utilizzo. Si combina perfettamente con altre offerte cloud di Google. Dati facilmente visibili e modificabili dalla loro interfaccia.

Regno

Aggiornamento 4/2020 MongoDB ha acquisito Realm e sta pianificando di combinarlo con MongoDB Stitch (discusso di seguito). Sembra molto eccitante .

Anche un archivio oggetti in tempo reale con sincronizzazione automatica della rete. Si pubblicizzano come "dispositivo prima" e il video dimostrativo mostra come i dispositivi gestiscono la connettività di rete sporadica o con perdita di dati.

Offrono una versione gratuita dell'archivio oggetti ospitato sui propri server o in una soluzione cloud come AWS o Azure. È inoltre possibile creare archivi in ​​memoria che non persistono con il dispositivo, archivi di soli dispositivi che non si sincronizzano con il server, archivi di server di sola lettura e l'opzione di lettura / scrittura completa per la sincronizzazione su uno o più dispositivi. Hanno opzioni professionali e aziendali che costano più in anticipo al mese rispetto a Firebase.

A differenza di Firebase, tutte le funzionalità di Realm sono supportate in React Native e Xamarin, proprio come nelle app Swift / ObjC / Java (native).

I tuoi dati sono legati ad oggetti nel tuo codice. Poiché sono oggetti definiti, si dispone di uno schema e il controllo della versione è un must per la sanità mentale del codice. L'accesso diretto è disponibile tramite gli strumenti della GUI forniti da Realm. I file di dati sul dispositivo sono compatibili multipiattaforma.

Conclusione: primo dispositivo, sincronizzazione opzionale con piani gratuiti ea pagamento. Tutte le funzionalità supportate in React Native. Ridimensionamento orizzontale più costoso di Firebase.

iCloud

Onestamente non ho giocato molto con questo, ma lo farò nel prossimo futuro.

Se si dispone di un'app nativa che utilizza CloudKit, è possibile utilizzare CloudKit JS per connettersi ai contenitori dell'app da un'app Web (o, nel nostro caso, React Native). In questo scenario, probabilmente avresti un'app iOS nativa e un'app Android nativa React.

Come Realm, questo memorizza i dati localmente e li sincronizza su iCloud quando possibile. Esistono negozi pubblici per la tua app e negozi privati ​​per ogni cliente. I clienti possono persino scegliere di condividere alcuni dei loro negozi o oggetti con altri utenti.

Non so quanto sia facile accedere ai dati grezzi; gli schemi possono essere impostati sul sito di Apple.

Conclusione: eccezionale per le app con targeting Apple.

Couchbase

Grande nome, molte grandi aziende dietro di esso. C'è una Community Edition e Enterprise Edition con i costi di supporto standard.

Hanno un tutorial sul loro sito per collegare cose a React Native. Inoltre non ho trascorso molto tempo su questo, ma sembra essere una valida alternativa al Realm in termini di funzionalità. Non so quanto sia facile accedere ai tuoi dati al di fuori della tua app o delle API che crei.

[Modifica: trovato un link più vecchio che parla di Couchbase e CouchDB, e CouchDB potrebbe essere un'altra opzione da considerare. I due sono prodotti storicamente correlati ma attualmente completamente diversi. Vedi questo confronto .]

Conclusione: sembra avere capacità simili a quelle del Reame. Può essere solo dispositivo o sincronizzato. Ho bisogno di provarlo.

MongoDB

Aggiornamento 4/2020

Mongo ha acquisito Realm e prevede di combinare MongoDB Stitch (discussa di seguito) con Realm (discussa sopra).

Sto usando questo lato server per un pezzo dell'app che utilizza AsyncStorage localmente. Mi piace che tutto sia archiviato come oggetti JSON, rendendo molto semplice la trasmissione ai dispositivi client. Nel mio caso d'uso, viene utilizzato come cache tra un fornitore upstream di dati della guida TV e i miei dispositivi client.

Non esiste una struttura rigida ai dati, come uno schema, quindi ogni oggetto viene archiviato come "documento" facilmente ricercabile, filtrabile, ecc. Oggetti JSON simili potrebbero avere attributi (ma diversi) aggiuntivi o oggetti figlio, consentendo un molta flessibilità nel modo in cui strutturi i tuoi oggetti / dati.

Non ho provato alcun client per funzionalità di sincronizzazione server, né l'ho usato incorporato. Reagisce Il codice nativo per MongoDB esiste.

Conclusione: soluzione NoSQL solo locale, nessuna opzione di sincronizzazione ovvia come Realm o Firebase.

Aggiornamento 2/2019

MongoDB ha un "prodotto" (o servizio) chiamato Stitch. Poiché i client (nel senso di browser Web e telefoni) non dovrebbero parlare direttamente con MongoDB (fatto dal codice sul tuo server), hanno creato un front-end senza server con cui le tue app possono interfacciarsi, se scegli di utilizzare il loro soluzione ospitata (Atlas). La loro documentazione fa apparire che esiste una possibile opzione di sincronizzazione.

Questo articolo di dicembre 2018 parla dell'utilizzo di React Native, Stitch e MongoDB in un'app di esempio, con altri esempi collegati nel documento ( https://www.mongodb.com/blog/post/building-ios-and-android-apps -con-il-mongodb-stitch-reagire-nativo-sdk ).

Twilio Sync

Un'altra opzione NoSQL per la sincronizzazione è Twilio's Sync. Dal loro sito: "La sincronizzazione consente di gestire lo stato su qualsiasi numero di dispositivi in ​​tempo reale su larga scala senza dover gestire alcuna infrastruttura di back-end".

L'ho considerato un'alternativa a Firebase per uno dei suddetti progetti, soprattutto dopo aver parlato con entrambi i team. Mi piacciono anche i loro altri strumenti di comunicazione e li ho usati per inviare SMS da una semplice app Web.

[Modifica] Ho trascorso un po 'di tempo con Realm da quando l'ho scritto in origine. Mi piace come non devo scrivere un'API per sincronizzare i dati tra l'app e il server, in modo simile a Firebase. Anche le funzioni senza server sembrano essere davvero utili con questi due, limitando la quantità di codice di backend che devo scrivere.

Adoro la flessibilità dell'archivio dati MongoDB, quindi sta diventando la mia scelta per il lato server delle app basate sul Web e altre connessioni richieste.

Ho trovato RESTHeart , che crea un'API RESTful molto semplice e scalabile su MongoDB. Non dovrebbe essere troppo difficile costruire un componente React (nativo) che legge e scrive oggetti JSON su RESTHeart, che a loro volta li passa a / da MongoDB.

[Modifica] Ho aggiunto informazioni su come sono memorizzati i dati. A volte è importante sapere quanto lavoro potresti svolgere durante lo sviluppo e il test se devi modificare e testare i dati.

Modifiche 2/2019 Ho sperimentato diverse di queste opzioni durante la progettazione di un progetto ad alta concorrenza l'anno scorso (2018). Alcuni di loro menzionano limiti di concorrenza rigidi nella loro documentazione (credo che Firebase ne avesse uno difficile a 10.000 connessioni, credo, mentre quello di Twilio era un limite morbido che poteva essere superato, secondo le discussioni con entrambi i team di AltConf).

Se stai progettando un'app da decine a centinaia di migliaia di utenti, preparati a ridimensionare il back-end dei dati di conseguenza.

Veloce e sporco: basta usare Redux + reagire-redux + redux-persist + AsyncStorage per reagire nativo.

Si adatta quasi perfettamente al mondo nativo reattivo e funziona come un fascino sia per Android che per iOS. Inoltre, c'è una solida comunità attorno ad essa e molte informazioni.

Per un esempio funzionante, vedere F8App da Facebook.

Quali sono le diverse opzioni per la persistenza dei dati?

Con reagire nativo, probabilmente si desidera utilizzare redux e redux-persist. Può utilizzare più motori di archiviazione. AsyncStorage e redux-persist-filesystem-storage sono le opzioni per RN.

Ci sono altre opzioni come Firebase o Realm, ma non ho mai usato quelle su un progetto RN.

Per ciascuno, quali sono i limiti di tale persistenza (ovvero quando i dati non sono più disponibili)? Ad esempio: quando si chiude l'applicazione, si riavvia il telefono, ecc.

Usando redux + redux-persist puoi definire ciò che è persistente e ciò che non lo è. Se non persistono, i dati esistono mentre l'app è in esecuzione. Se persistono, i dati persistono tra le esecuzioni delle app (chiudi, apri, riavvia il telefono, ecc.).

AsyncStorage ha un limite predefinito di 6 MB su Android. È possibile configurare un limite maggiore (su codice Java) o utilizzare redux-persist-filesystem-storage come motore di archiviazione per Android.

Per ognuno, ci sono differenze (oltre alla configurazione generale) tra l'implementazione in iOS vs Android?

Utilizzando redux + redux-persist + AsyncStorage, l'installazione è esattamente la stessa su Android e iOS.

Come si confrontano le opzioni per l'accesso ai dati offline? (o come viene gestito l'accesso offline?)

Usando redux, l'accesso all'offiline è quasi automatico grazie alle sue parti di design (creatori di azioni e riduttori).

Tutti i dati recuperati e archiviati sono disponibili, è possibile archiviare facilmente dati aggiuntivi per indicare lo stato (recupero, esito positivo, errore) e l'ora in cui sono stati recuperati. Normalmente, la richiesta di un recupero non invalida i dati più vecchi e i componenti si aggiornano solo quando vengono ricevuti nuovi dati.

Lo stesso vale nell'altra direzione. È possibile archiviare i dati che si stanno inviando al server e che sono ancora in sospeso e gestirli di conseguenza.

Ci sono altre considerazioni che dovrei tenere a mente?

React promuove un modo reattivo di creare app e Redux si adatta molto bene ad esso. Dovresti provarlo prima di usare solo un'opzione che utilizzeresti nella tua normale app Android o iOS. Inoltre, troverai molti più documenti e aiuto per quelli.

Le persone sopra hanno colpito le note giuste per l'archiviazione, anche se se devi anche considerare tutti i dati PII che devono essere archiviati, puoi anche inserirli nel portachiavi usando qualcosa come https://github.com/oblador/react-native-keychain poiché ASyncStorage non è crittografato. Può essere applicato come parte della configurazione persist in qualcosa come redux-persist.

puoi utilizzare l' archiviazione di sincronizzazione più semplice da utilizzare rispetto all'archiviazione asincrona. questa libreria è fantastica che utilizza l'archiviazione asincrona per salvare i dati in modo asincrono e utilizza la memoria per caricare e salvare i dati istantaneamente in modo sincrono, quindi salviamo i dati asincroni in memoria e li utilizziamo nella sincronizzazione delle app, quindi è fantastico.

import SyncStorage from 'sync-storage';

SyncStorage.set('foo', 'bar');
const result = SyncStorage.get('foo');
console.log(result); // 'bar'

puoi usare Realm o Sqlite se vuoi gestire tipi di dati complessi.

Altrimenti vai con asynstorage nativo reattivo incorporato

Non abbiamo bisogno di redux-persist, possiamo semplicemente usare redux per la persistenza.

reazioni-redux + AsyncStorage = redux-persist

quindi all'interno del file createotre è sufficiente aggiungere queste righe

store.subscribe(async()=> await AsyncStorage.setItem("store", JSON.stringify(store.getState())))

questo aggiornerà AsyncStorage ogni volta che ci sono alcune modifiche nell'archivio redux.

Quindi caricare il negozio convertito json. quando mai l'app viene caricata. e impostare nuovamente il negozio.

Perché redux-persist crea problemi quando si utilizza wix reag-native-navigation. In tal caso, preferisco utilizzare il semplice redux con la funzione di sottoscrizione sopra