Quelles sont mes options pour le stockage des données lorsque j'utilise React Native ? (iOS et Android)

Question

Je suis encore nouveau dans le monde de React Native, et généralement dans le monde mobile/natif aussi, et je trouve que la documentation manque un peu quand il s'agit de la persistance des données.

Quelles sont mes options pour stocker des données dans React Native et les implications de chaque type ? Par exemple, je vois qu'il existe un stockage local et un stockage asynchrone, mais je vois aussi des choses comme Realm, et je ne sais pas comment tout cela pourrait fonctionner avec une base de données extérieure.

Je veux spécifiquement savoir :

• Quelles sont les différentes options de persistance des données ?
• Pour chacune, quelles sont les limites de cette persistance (c'est-à-dire quand les données ne sont-elles plus disponibles) ? Par exemple : à la fermeture de l'application, au redémarrage du téléphone, etc.
• Pour chacun d'entre eux, y a-t-il des différences (autres que la configuration générale) entre la mise en œuvre dans iOS et Android ?
• Comment les options se comparent-elles pour accéder aux données hors ligne ? (ou comment l'accès hors ligne est-il généralement géré ?)
• Y a-t-il d'autres considérations que je devrais garder à l'esprit ?

Merci pour votre aide !

Answer 1

Voici ce que j'ai appris en déterminant la meilleure façon d'aller de l'avant avec quelques-uns de mes projets d'applications en cours.

Stockage asynchrone (anciennement "intégré" à React Native, maintenant déplacé seul)

J'utilise AsyncStorage pour une application en production. Le stockage reste local à l'appareil, n'est pas crypté (comme mentionné dans une autre réponse), disparaît si vous supprimez l'application, mais doit être sauvegardé dans le cadre des sauvegardes de votre appareil et persiste pendant les mises à jour (à la fois les mises à jour natives comme TestFlight et les mises à jour de code via CodePush).

Conclusion : Stockage local ; vous fournissez votre propre solution de synchronisation/sauvegarde.

SQLite

D'autres projets sur lesquels j'ai travaillé ont utilisé sqlite3 pour le stockage des applications. Cela vous donne une expérience similaire à SQL, avec des bases de données compressibles qui peuvent également être transmises vers et depuis l'appareil. Je n'ai pas eu l'occasion de les synchroniser avec un back-end, mais j'imagine que diverses bibliothèques existent. Il existe des bibliothèques RN pour se connecter à SQLite.

Les données sont stockées dans le format traditionnel des bases de données, avec des bases de données, des tables, des clés, des indices, etc. tous enregistrés sur le disque dans un format binaire. L'accès direct aux données est disponible via la ligne de commande ou les applications qui ont des pilotes SQLite.

Conclusion : Stockage local ; vous fournissez la synchronisation et la sauvegarde.

Firebase

Firebase offre, entre autres, une base de données noSQL en temps réel ainsi qu'un magasin de documents JSON (comme MongoDB) destinés à maintenir la synchronisation d'un à n nombre de clients. La documentation parle de persistance hors ligne, mais uniquement pour le code natif (Swift/Obj-C, Java). La propre option JavaScript de Google ("Web") qui est utilisée par React Native ne fournit pas d'option de stockage en cache (voir la mise à jour du 18 février ci-dessous). La bibliothèque est écrite en partant du principe qu'un navigateur Web va se connecter, et qu'il y aura donc une connexion semi-persistante. Vous pourriez probablement écrire un mécanisme de mise en cache local pour compléter les appels de stockage Firebase, ou vous pourriez écrire un pont entre les bibliothèques natives et React Native.

Mise à jour 2/2018 J'ai depuis trouvé React Native Firebase qui fournit une interface JavaScript compatible avec les bibliothèques natives d'iOS et d'Android (faisant ce que Google aurait probablement pu/devrait faire), vous offrant tous les avantages des bibliothèques natives avec en prime le support de React Native. Avec l'introduction par Google d'un magasin de documents JSON à côté de la base de données en temps réel, j'accorde à Firebase un bon second regard pour certaines applications en temps réel que je prévois de construire.

La base de données en temps réel est stockée sous la forme d'un arbre de type JSON que vous pouvez modifier sur le site web et importer/exporter assez simplement.

Conclusion : Avec react-native-firebase, RN obtient les mêmes avantages que Swift et Java. [Il s'adapte bien aux appareils connectés au réseau. Faible coût pour une faible utilisation. Se combine bien avec d'autres offres de Google Cloud. Données facilement visibles et modifiables à partir de leur interface.

Realm

Mise à jour 4/2020 MongoDB a acquis Realm et prévoit de le combiner avec MongoDB Stitch (discuté ci-dessous). Cela semble très excitant .

Mise à jour 9/2020 J'ai utilisé Realm et Stitch : Les API de Stitch permettaient essentiellement à une application JS (React Native ou web) de parler directement à la base de données Mongo au lieu de passer par un serveur API que vous construisez vous-même.

Realm était destiné à synchroniser des parties de la base de données à chaque fois que des modifications étaient apportées.

La combinaison des deux devient un peu confuse. L'API anciennement connue sous le nom de Stitch fonctionne toujours comme les appels traditionnels de requête et de mise à jour de Mongo, tandis que la nouvelle technologie Realm s'attache aux objets dans le code et gère la synchronisation toute seule... en grande partie. Je suis encore en train de travailler sur la bonne façon de faire les choses dans un projet, qui utilise SwiftUI, donc c'est un peu hors sujet. Mais c'est tout de même prometteur et intéressant.

---

Egalement un magasin d'objets en temps réel avec synchronisation automatique du réseau. Ils se vantent d'être "device first" et la vidéo de démonstration montre comment les appareils gèrent une connectivité réseau sporadique ou déficiente.

Elle propose une version gratuite du magasin d'objets que vous hébergez sur vos propres serveurs ou dans une solution en nuage comme AWS ou Azure. Vous pouvez également créer des magasins en mémoire qui ne persistent pas avec l'appareil, des magasins réservés aux appareils qui ne se synchronisent pas avec le serveur, des magasins de serveur en lecture seule et l'option de lecture-écriture complète pour la synchronisation entre un ou plusieurs appareils. Il existe des options professionnelles et d'entreprise qui coûtent plus cher par mois que Firebase.

Contrairement à Firebase, toutes les fonctionnalités de Realm sont prises en charge dans React Native et Xamarin, tout comme elles le sont dans les applications Swift/ObjC/Java (natives).

Vos données sont liées à des objets dans votre code. Comme il s'agit d'objets définis, vous disposez d'un schéma et le contrôle de la version est indispensable pour garantir l'intégrité du code. L'accès direct est disponible via les outils GUI fournis par Realm. Les fichiers de données sur l'appareil sont compatibles avec toutes les plates-formes.

Conclusion : Device first, synchronisation optionnelle avec des plans gratuits et payants. Toutes les fonctionnalités sont supportées dans React Native. Mise à l'échelle horizontale plus chère que Firebase.

iCloud

Honnêtement, je n'ai pas beaucoup joué avec celui-ci, mais je le ferai dans un avenir proche.

Si vous avez une application native qui utilise CloudKit, vous pouvez utiliser CloudKit JS pour vous connecter aux conteneurs de votre application depuis une application web (ou, dans notre cas, React Native). Dans ce scénario, vous aurez probablement une application native iOS et une application React Native Android.

Comme Realm, il stocke les données localement et les synchronise avec iCloud lorsque cela est possible. Il existe des magasins publics pour votre application et des magasins privés pour chaque client. Les clients peuvent même choisir de partager certains de leurs magasins ou objets avec d'autres utilisateurs.

Je ne sais pas s'il est facile d'accéder aux données brutes ; les schémas peuvent être établis sur le site d'Apple.

Conclusion : Excellent pour les applications destinées à Apple.

Couchbase

Un grand nom, beaucoup de grandes entreprises derrière lui. Il existe une édition communautaire et une édition entreprise avec les coûts d'assistance standard.

Il y a un tutoriel sur leur site pour connecter des choses à React Native. Je n'ai pas non plus passé beaucoup de temps sur celui-ci, mais il semble être une alternative viable à Realm en termes de fonctionnalités. Je ne sais pas s'il est facile d'accéder à vos données en dehors de votre application ou de toute API que vous construisez.

[Edit : Found an older link that talks about Couchbase and CouchDB, and CouchDB may be yet another option to consider. Les deux sont historiquement liés mais sont actuellement des produits complètement différents. Voir cette comparaison .]

Conclusion : Semble avoir des capacités similaires à celles de Realm. Peut être utilisé sur un seul appareil ou être synchronisé. Je dois l'essayer.

MongoDB

Mise à jour 4/2020

Mongo a acquis Realm et prévoit de combiner MongoDB Stitch (discuté ci-dessous) avec Realm (discuté ci-dessus).

---

Je l'utilise côté serveur pour une partie de l'application qui utilise AsyncStorage localement. J'aime que tout soit stocké sous forme d'objets JSON, ce qui rend la transmission aux périphériques clients très simple. Dans mon cas d'utilisation, il est utilisé comme un cache entre un fournisseur en amont de données de guide TV et mes appareils clients.

Les données ne sont pas structurées, comme un schéma, et chaque objet est stocké comme un "document" facilement consultable, filtrable, etc. Des objets JSON similaires peuvent avoir des attributs ou des objets enfants supplémentaires (mais différents), ce qui permet une grande flexibilité dans la façon dont vous structurez vos objets/données.

Je n'ai pas essayé les fonctions de synchronisation client-serveur, et je ne les ai pas utilisées de manière intégrée. Le code React Native pour MongoDB existe.

Conclusion : Solution NoSQL uniquement locale, pas d'option de synchronisation évidente comme Realm ou Firebase.

Mise à jour 2/2019

MongoDB propose un "produit" (ou service) appelé Stitch. Puisque les clients (au sens des navigateurs web et des téléphones) ne devraient pas parler directement à MongoDB (cela est fait par le code sur votre serveur), ils ont créé un front-end sans serveur avec lequel vos applications peuvent s'interfacer, si vous choisissez d'utiliser leur solution hébergée (Atlas). Leur documentation laisse entendre qu'il existe une option de synchronisation possible.

Cette note de décembre 2018 traite de l'utilisation de React Native, de Stitch et de MongoDB dans une application type, avec d'autres exemples liés dans le document ( https://www.mongodb.com/blog/post/building-ios-and-Android-apps-with-the-mongodb-stitch-react-native-sdk ).

Twilio Sync

Une autre option NoSQL pour la synchronisation est Sync de Twilio. Extrait de leur site : "Sync vous permet de gérer l'état de n'importe quel nombre d'appareils en temps réel à l'échelle sans avoir à gérer une quelconque infrastructure dorsale."

Je l'ai envisagé comme une alternative à Firebase pour l'un des projets susmentionnés, surtout après avoir discuté avec les deux équipes. J'aime aussi leurs autres outils de communication et je les ai utilisés pour envoyer des mises à jour par SMS à partir d'une simple application Web.

---

[J'ai passé un peu de temps avec Realm depuis que j'ai écrit ceci. J'aime le fait de ne pas avoir à écrire une API pour synchroniser les données entre l'application et le serveur, comme avec Firebase. Les fonctions sans serveur semblent également être très utiles avec ces deux-là, limitant la quantité de code backend que je dois écrire.

J'aime la flexibilité du magasin de données MongoDB, qui devient donc mon choix pour le côté serveur des applications Web et autres applications nécessitant une connexion.

J'ai trouvé RESTHeart qui crée une API RESTful très simple et évolutive vers MongoDB. Il ne devrait pas être trop difficile de construire un composant React (Native) qui lit et écrit des objets JSON dans RESTHeart, qui à son tour les transmet à/de MongoDB.

---

[J'ai ajouté des informations sur la façon dont les données sont stockées. Il est parfois important de connaître la charge de travail à laquelle on s'expose pendant le développement et les tests si l'on doit modifier et tester les données.

---

Modifications 2/2019 J'ai expérimenté plusieurs de ces options lors de la conception d'un projet à monnaie forte l'année dernière (2018). Certains d'entre eux mentionnent des limites de simultanéité dures et souples dans leur documentation (Firebase en avait une dure à 10 000 connexions, je crois, tandis que celle de Twilio était une limite souple qui pouvait être heurtée, selon les discussions avec les deux équipes à AltConf).

Si vous concevez une application pour des dizaines ou des centaines de milliers d'utilisateurs, préparez-vous à faire évoluer le backend de données en conséquence.

Answer 2

Simple et rapide : il suffit d'utiliser Redux + react-redux + redux-persiste + AsyncStorage pour react-native.

Il s'adapte presque parfaitement au monde react native et fonctionne comme un charme pour Android et ios. De plus, il existe une solide communauté autour de lui, et de nombreuses informations.

Pour un exemple concret, voir le F8App de Facebook.

Quelles sont les différentes options de persistance des données ?

Avec react native, vous voulez probablement utiliser redux et redux-persist. Il peut utiliser plusieurs moteurs de stockage. AsyncStorage et redux-persist-filesystem-storage sont les options pour RN.

Il existe d'autres options comme Firebase ou Realm, mais je ne les ai jamais utilisées sur un projet de RN.

Pour chacune, quelles sont les limites de cette persistance (c'est-à-dire quand les données ne sont-elles plus disponibles) ? Par exemple : à la fermeture de l'application, au redémarrage du téléphone, etc.

En utilisant redux + redux-persist, vous pouvez définir ce qui est persistant et ce qui ne l'est pas. Lorsqu'elles ne sont pas persistantes, les données existent pendant l'exécution de l'application. Lorsqu'elles sont persistantes, les données persistent entre les exécutions de l'application (fermeture, ouverture, redémarrage du téléphone, etc).

AsyncStorage a une limite par défaut de 6 Mo sur Android. Il est possible de configurer une limite plus importante (sur le code Java) ou d'utiliser redux-persist-filesystem-storage comme moteur de stockage pour Android.

Pour chacun d'entre eux, y a-t-il des différences (autres que la configuration générale) entre la mise en œuvre dans iOS et Android ?

En utilisant redux + redux-persist + AsyncStorage, la configuration est exactement la même sur Android et iOS.

Comment les options se comparent-elles pour accéder aux données hors ligne ? (ou comment l'accès hors ligne est-il généralement géré ?)

Avec redux, l'accès hors ligne est presque automatique grâce à ses éléments de conception (créateurs et réducteurs d'actions).

Toutes les données que vous avez récupérées et stockées sont disponibles, vous pouvez facilement stocker des données supplémentaires pour indiquer l'état (récupération, succès, erreur) et l'heure à laquelle elles ont été récupérées. Normalement, la demande d'une extraction n'invalide pas les anciennes données et vos composants se mettent simplement à jour lorsque de nouvelles données sont reçues.

Il en va de même dans l'autre sens. Vous pouvez stocker les données que vous envoyez au serveur et qui sont encore en attente et les traiter en conséquence.

Y a-t-il d'autres considérations que je devrais garder à l'esprit ?

React favorise une manière réactive de créer des applications et Redux s'y adapte très bien. Vous devriez l'essayer avant de vous contenter d'utiliser une option que vous utiliseriez dans votre application Android ou iOS habituelle. En outre, vous trouverez beaucoup plus de documents et d'aide pour ces applications.

Answer 3

Les personnes citées plus haut ont touché les bonnes notes pour le stockage, mais si vous devez également prendre en compte les données PII qui doivent être stockées, vous pouvez également les stocker dans le trousseau de clés en utilisant quelque chose comme https://github.com/oblador/react-native-keychain puisque ASyncStorage n'est pas crypté. Il peut être appliqué en tant que partie de la configuration persist dans quelque chose comme redux-persist.

Answer 4

Nous n'avons pas besoin de redux-persist, nous pouvons simplement utiliser redux pour la persistance.

react-redux + AsyncStorage = redux-persist

donc à l'intérieur du fichier createsotre ajoutez simplement ces lignes

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

ceci mettra à jour l'AsyncStorage à chaque fois qu'il y aura des changements dans le magasin redux.

Puis chargez le magasin converti en json. quand l'application se charge, et définissez à nouveau le magasin.

Parce que redux-persist crée des problèmes lors de l'utilisation de wix react-native-navigation. Si c'est le cas, je préfère utiliser redux simple avec la fonction d'abonné ci-dessus.

Answer 5

Vous pouvez utiliser stockage de synchronisation qui est plus facile à utiliser que le stockage asynchrone. cette bibliothèque est géniale car elle utilise le stockage asynchrone pour sauvegarder les données de manière asynchrone et utilise la mémoire pour charger et sauvegarder les données instantanément de manière synchrone, ainsi nous sauvegardons les données de manière asynchrone en mémoire et les utilisons dans la synchronisation de l'application, donc c'est génial.

import SyncStorage from 'sync-storage';

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