Quelles sont mes options pour stocker des données lorsque j'utilise React Native? (iOS et Android)
Je suis encore nouveau dans le monde natal React, et plus généralement dans le monde mobile/natif, et je trouve que la documentation manque un peu en ce qui concerne 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 comprends pas comment tout cela fonctionnerait avec une base de données externe.
Je veux spécifiquement savoir:
- Quelles sont les différentes options pour la persistance des données?
- Pour chacune d’elles, quelles sont les limites de cette persistance (c’est-à-dire quand les données ne sont plus disponibles)? Par exemple: lors de la fermeture de l'application, du redémarrage du téléphone, etc.
- Existe-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 est-ce que l'accès hors connexion est généralement géré?)
- Y a-t-il d'autres considérations que je devrais garder à l'esprit?
Merci de votre aide!
Voici ce que j'ai appris en déterminant le meilleur moyen d'avancer avec quelques-uns de mes projets d'application actuels.
Stockage asynchrone ("intégré" à React Native)
J'utilise AsyncStorage pour une application en production. Le stockage reste local sur le périphérique, n'est pas crypté (comme indiqué dans une autre réponse), disparaît si vous supprimez l'application, mais doit être enregistré dans le cadre des sauvegardes de votre périphérique et persiste pendant les mises à niveau (mises à niveau natives comme TestFlight et 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 d'applications. Cela vous donne une expérience semblable à SQL, avec des bases de données compressibles qui peuvent également être transmises de et vers le périphérique. Je n'ai pas d'expérience avec la synchronisation sur un back-end, mais j'imagine qu'il existe plusieurs bibliothèques. Il existe des bibliothèques RN pour se connecter à SQLite.
Les données sont stockées dans votre format de base de données traditionnel avec des bases de données, des tables, des clés, des index, etc., le tout étant sauvegardé sur disque dans un format binaire. Un accès direct aux données est disponible via une ligne de commande ou des applications dotées de 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é à maintenir un nombre nodal de clients synchronisé. Les docs parlent de persistance hors ligne, mais uniquement pour le code natif (Swift/Obj-C, Java). L'option JavaScript de Google ("Web") utilisée par React Native ne fournit pas d'option de stockage en cache (voir Mise à jour 2/18 ci-dessous). La bibliothèque est écrite avec l'hypothèse qu'un navigateur Web va se connecter, il y aura donc une connexion semi-persistante. Vous pouvez probablement écrire un mécanisme de mise en cache local pour compléter les appels de stockage Firebase ou 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 iOS et Android (faisant ce que Google aurait probablement/dû faire). , vous donnant tous les goodies des bibliothèques natives avec le bonus de React support natif. Avec l'introduction d'un magasin de documents JSON par Google à côté de la base de données en temps réel, je donne à Firebase un second aperçu de certaines applications en temps réel que je prévois de créer.
La base de données en temps réel est stockée sous forme d'arborescence de type JSON que vous pouvez modifier sur le site Web et importer/exporter très simplement.
Conclusion: avec react-native-firebase, RN bénéficie des mêmes avantages que Swift et Java. [/ update] s'adapte bien aux périphériques connectés au réseau. Faible coût pour une faible utilisation. Se combine bien avec les autres offres de Google Cloud. Données facilement visibles et modifiables à partir de leur interface.
Domaine
Egalement un magasin d'objets en temps réel avec synchronisation réseau automatique. Ils se vantent d’être "appareil d’abord" et la vidéo de démonstration montre comment les appareils gèrent une connectivité réseau sporadique ou avec pertes.
Ils offrent une version gratuite du magasin d'objets que vous hébergez sur vos propres serveurs ou dans une solution de cloud telle qu'AWS ou Azure. Vous pouvez également créer des magasins en mémoire qui ne persistent pas avec le périphérique, des magasins de périphérique uniquement 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 sur un ou plusieurs périphériques. Ils disposent d'options professionnelles et professionnelles qui coûtent plus cher chaque mois que Firebase.
Contrairement à Firebase, toutes les fonctionnalités de Realm sont prises en charge dans React Native et Xamarin, tout comme dans les applications Swift/ObjC/Java (natives).
Vos données sont liées aux objets de votre code. Comme il s’agit d’objets définis, vous disposez d’un schéma et le contrôle de version est indispensable pour la santé du code. L'accès direct est disponible via les outils graphiques fournis par Realm. Les fichiers de données sur l'appareil sont compatibles entre plates-formes.
Conclusion: appareil d'abord, synchronisation optionnelle avec les forfaits gratuits et payants. Toutes les fonctionnalités prises en charge dans React Native. La mise à l'échelle horizontale est 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 à partir d'une application Web (ou, dans notre cas, React Native). Dans ce scénario, vous auriez probablement une application iOS native et une application React Native Android.
Comme Realm, cela 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 à quel point il est facile d'accéder aux données brutes. les schémas peuvent être configurés sur le site Apple.
Conclusion: Idéal pour les applications ciblées par Apple.
Couchbase
Grand nom, beaucoup de grandes entreprises derrière elle. Il existe une Community Edition et une Enterprise Edition avec les coûts de support standard.
Ils ont un tutoriel sur leur site pour relier des choses à React Native. Je n'ai pas passé beaucoup de temps sur celui-ci, mais cela semble être une alternative viable à Realm en termes de fonctionnalité. Je ne sais pas à quel point il est facile d'accéder à vos données en dehors de votre application ou des API que vous construisez.
[Edit: trouvé un ancien lien qui parle de Couchbase et CouchDB, et CouchDB peut être une autre option à considérer. Les deux sont des produits historiquement liés mais actuellement complètement différents. Voir cette comparaison .]
Conclusion: semble avoir des capacités similaires à celles de Realm. Peut être uniquement sur l'appareil ou synchronisé. J'ai besoin d'essayer.
MongoDB
J'utilise ce côté serveur pour une partie de l'application qui utilise localement AsyncStorage. J'aime que tout soit stocké sous la forme d'objets JSON, ce qui facilite grandement la transmission aux périphériques clients. Dans mon cas d'utilisation, il sert de cache entre un fournisseur de données de guide de télévision en amont et mes périphériques clients.
Il n’ya pas de structure dure dans les données, comme un schéma, donc chaque objet est stocké sous la forme d’un "document" qui peut être facilement recherché, filtré, etc. Les objets JSON similaires peuvent avoir des attributs supplémentaires (mais différents) ou des objets enfants, ce qui permet une beaucoup de flexibilité dans la structure de vos objets/données.
Je n’ai essayé aucune fonctionnalité de synchronisation client à serveur, ni l’ai intégrée. React Le code natif de MongoDB existe.
Conclusion: Solution NoSQL locale uniquement. Aucune option de synchronisation évidente comme Realm ou Firebase.
[Mise à jour 2/2019]
MongoDB a un "produit" (ou service) appelé Stitch. Étant donné que les clients (au sens des navigateurs Web et des téléphones) ne doivent pas parler directement à MongoDB (cela se fait par code sur votre serveur), ils ont créé une interface frontale sans serveur avec laquelle vos applications peuvent s’interfacer, si vous choisissez de les utiliser. solution hébergée (Atlas). Leur documentation fait apparaître qu’il existe une option de synchronisation possible.
Cet article de décembre 2018 décrit l'utilisation de React Native, Stitch et MongoDB dans un exemple d'application, avec d'autres exemples liés dans le document ( https://www.mongodb.com/blog/post/construire-ios-et-Android-apps-avec-le-mongodb-stitch-react-native-sdk ).
Twilio Sync
Une autre option NoSQL pour la synchronisation est la synchronisation de Twilio. Depuis leur site: "Sync vous permet de gérer l’état en temps réel, à l’échelle d’un nombre illimité de périphériques, sans avoir à gérer aucune infrastructure dorsale."
J'ai envisagé cela comme une alternative à Firebase pour l'un des projets susmentionnés, en particulier après avoir parlé aux 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.
[/Mise à jour]
[Edit] J'ai passé quelque temps avec Realm depuis que j'ai écrit ceci. J'aime le fait que je n'ai pas besoin d'écrire une API pour synchroniser les données entre l'application et le serveur, comme avec Firebase. Les fonctions sans serveur semblent aussi vraiment utiles avec ces deux logiciels, limitant ainsi la quantité de code que je dois écrire.
J'adore la flexibilité du magasin de données MongoDB. Cela devient donc mon choix pour le côté serveur des applications Web et autres applications nécessitant une connexion.
J'ai trouvé RESTHeart , ce qui crée une API RESTful très simple et évolutive pour MongoDB. Il ne devrait pas être trop difficile de créer un composant React (natif) qui lit et écrit des objets JSON dans RESTHeart, qui les transmet à leur tour à MongoDB.
[Modifier] J'ai ajouté des informations sur la manière dont les données sont stockées. Parfois, il est important de savoir combien de travail vous êtes susceptible d’être pendant le développement et les tests si vous devez modifier et tester les données.
[Mise à jour 2/2019] J'ai expérimenté plusieurs de ces options lors de la conception d'un projet à haute simultanéité l'année dernière (2018). Certains d'entre eux mentionnent des limites strictes et souples de concurrence dans leur documentation (Firebase en avait une difficile à 10 000 connexions, alors que celle de Twilio était une limite souple qui pourrait être dépassée, selon les discussions avec les deux équipes chez AltConf).
Si vous concevez une application pour des dizaines à des centaines de milliers d'utilisateurs, soyez prêt à redimensionner le système de données en conséquence.
Rapide et sale: utilisez juste Redux + react-redux + redux-persist + AsyncStorage pour react-native.
Il convient presque parfaitement au monde natal réagi et fonctionne à merveille pour Android et ios. En outre, il existe une solide communauté autour de lui et de nombreuses informations.
Pour un exemple de travail, voir le F8App de Facebook.
Quelles sont les différentes options pour la persistance des données?
Avec react native, vous souhaiterez 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 telles que Firebase ou Realm, mais je n'ai jamais utilisé celles d'un projet RN.
Pour chacune d’elles, quelles sont les limites de cette persistance (c’est-à-dire quand les données ne sont plus disponibles)? Par exemple: lors de la fermeture de l'application, du 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 persistent pas, les données existent pendant l'exécution de l'application. En cas de persistance, les données persistent entre les exécutions d'applications (fermer, ouvrir, redémarrer le téléphone, etc.).
AsyncStorage a une limite par défaut de 6 Mo sur Android. Il est possible de configurer une limite plus grande (sur le code Java) ou d'utiliser redux-persist-filesystem-storage-storage comme moteur de stockage pour Android.
Existe-t-il des différences (autres que la configuration générale) entre la mise en œuvre dans iOS et Android?
Avec redux + redux-persist + AsyncStorage, la configuration est identique sur Android et iOS.
Comment les options se comparent-elles pour accéder aux données hors ligne? (ou comment est-ce que l'accès hors connexion est généralement géré?)
Grâce à redux, l’accès offiline est presque automatique grâce à ses éléments de conception (créateurs d’action et réducteurs).
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 (extraction, succès, erreur) et l'heure à laquelle elles ont été extraites. Normalement, demander une extraction n'invalide pas les anciennes données et vos composants se mettent simplement à jour lorsque de nouvelles données sont reçues.
La même chose s'applique dans l'autre sens. Vous pouvez stocker les données que vous envoyez au serveur et qui sont toujours en attente et les gérer 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 intègre très bien. Vous devriez l'essayer avant d'utiliser simplement une option que vous utiliseriez dans votre application Android ou iOS normale. En outre, vous trouverez beaucoup plus de documents et d’aide pour ceux-ci.
Les personnes ci-dessus respectent les bonnes notes en matière de 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 en utilisant quelque chose comme https://github.com/oblador/react -native-keychain puisque ASyncStorage n'est pas crypté. Il peut être appliqué dans le cadre de la configuration de persist dans quelque chose comme redux-persist.
vous pouvez utiliser sync storage , qui est plus facile à utiliser que le stockage async. Cette bibliothèque est géniale: elle utilise le stockage asynchrone pour enregistrer les données de manière asynchrone et utilise la mémoire pour charger et enregistrer les données instantanément de manière synchrone. Nous enregistrons donc les données en mémoire asynchrone et les utilisons dans la synchronisation d'applications, ce qui est formidable.
import SyncStorage from 'sync-storage';
SyncStorage.set('foo', 'bar');
const result = SyncStorage.get('foo');
console.log(result); // 'bar'
vous pouvez utiliser Realm ou Sqlite si vous souhaitez gérer des types de données complexes.
Sinon aller avec intégré asynstorage natif de réaction
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 crée votre fichier simplement ajouter ces lignes
store.subscribe(async()=> await AsyncStorage.setItem("store", JSON.stringify(store.getState())))
cela mettra à jour AsyncStorage chaque fois que des changements seront apportés au magasin Redux.
Puis chargez le magasin JSON converti. chaque fois que l'application se charge. et mettre le magasin à nouveau.
Parce que redux-persist crée des problèmes lors de l’utilisation de wix react-native-navigation. Si tel est le cas, je préfère utiliser une simple redux avec la fonction d'abonné ci-dessus.