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'application actuels.
Stockage asynchrone ("intégré" pour React Native)
J'utilise AsyncStorage pour une application en production. Le stockage reste local sur l'appareil, n'est pas chiffré (comme mentionné dans une autre réponse), disparaît si vous supprimez l'application, mais doit être enregistré dans le cadre des sauvegardes de votre appareil et persiste pendant les mises à niveau (les deux mises à niveau natives ala TestFlight et les mises à niveau 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 d'applications. Cela vous donne une expérience de type SQL, avec des bases de données compressibles qui peuvent également être transmises vers et depuis l'appareil. Je n'ai aucune expérience de leur synchronisation avec un serveur principal, mais j'imagine que différentes bibliothèques existent. 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. 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 des applications dotées de pilotes SQLite.
Conclusion: stockage local; vous fournissez la synchronisation et la sauvegarde.
Firebase
Firebase propose, entre autres, une base de données noSQL en temps réel avec un magasin de documents JSON (comme MongoDB) destiné à garder synchronisé 1 à n nombre de clients. Les documents 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 la mise à jour 2/18 ci-dessous). La bibliothèque est écrite avec l'hypothèse qu'un navigateur Web va se connecter, et donc il y aura 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 iOS et Android (faisant ce que Google aurait probablement pu / aurait dû faire), vous offrant tous les avantages des bibliothèques natives avec le bonus de React Prise en charge native. Avec l'introduction par Google d'un magasin de documents JSON à côté de la base de données en temps réel, je donne à Firebase un bon deuxième regard pour 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 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. [/ update] S'adapte bien aux périphériques connectés au réseau. Faible coût pour une faible utilisation. Se combine bien avec d'autres offres cloud de Google. Données facilement visibles et modifiables depuis leur interface.
Domaine
Mise à jour 4/2020
MongoDB a acquis Realm et prévoit de le combiner avec MongoDB Stitch (décrit ci-dessous). Cela semble très excitant .
Également un magasin d'objets en temps réel avec synchronisation automatique du réseau. Ils se présentent comme «les appareils d'abord» et la vidéo de démonstration montre comment les appareils gèrent la connectivité réseau sporadique ou avec perte.
Ils offrent une version gratuite du magasin d'objets que vous hébergez sur vos propres serveurs ou dans une solution cloud comme 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ériques uniquement qui ne se synchronisent pas avec le serveur, des magasins de serveurs en lecture seule et l'option de lecture-écriture complète pour la synchronisation sur un ou plusieurs périphériques. Ils ont des options professionnelles et d'entreprise qui coûtent plus cher par mois que Firebase.
Contrairement à Firebase, toutes les capacité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. Parce que ce sont des objets définis, vous avez un schéma et le contrôle de version est un must pour 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 multiplateforme.
Conclusion: Appareil d'abord, synchronisation en option avec les plans gratuits et payants. Toutes les fonctionnalités prises en charge dans React Native. La mise à l'échelle horizontale est plus coûteuse 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 Android React Native.
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 d'Apple.
Conclusion: idéal pour les applications ciblées par Apple.
Couchbase
Grand nom, beaucoup de grandes entreprises derrière. Il existe une édition communautaire et une édition entreprise avec les coûts de support standard.
Ils ont un tutoriel sur leur site pour connecter des choses à React Native. Je n'ai pas non plus consacré beaucoup de temps à celui-ci, mais il semble être une alternative viable à Realm en termes de fonctionnalités. 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 créez.
[Modifier: Trouvé un lien plus ancien qui parle de Couchbase et CouchDB, et CouchDB peut être encore 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 à Realm. Peut être uniquement sur l'appareil ou synchronisé. Je dois l'essayer.
MongoDB
Mise à jour 4/2020
Mongo a acquis Realm et prévoit de combiner MongoDB Stitch (décrit ci-dessous) avec Realm (décrit ci-dessus).
J'utilise ce côté serveur pour un morceau de l'application qui utilise AsyncStorage localement. J'aime que tout soit stocké en tant qu'objets JSON, ce qui rend la transmission aux périphériques clients très simple. Dans mon cas d'utilisation, il est utilisé comme cache entre un fournisseur en amont de données de guide TV et mes appareils clients.
Il n'y a pas de structure matérielle dans les données, comme un schéma, donc chaque objet est stocké comme un "document" qui peut être facilement recherché, filtrable, etc. Des objets JSON similaires pourraient avoir des attributs ou des objets enfants supplémentaires (mais différents), permettant une beaucoup de flexibilité dans la façon dont vous structurez vos objets / données.
Je n'ai essayé aucune fonction de synchronisation client-serveur et je ne l'ai pas utilisée de manière intégrée. Le code natif React pour MongoDB existe.
Conclusion: solution NoSQL locale uniquement, pas d'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 (dans le sens des navigateurs Web et des téléphones) ne doivent pas parler directement à MongoDB (cela se fait par le code sur votre serveur), ils ont créé une interface sans serveur avec laquelle vos applications peuvent s'interfacer, si vous choisissez d'utiliser leur solution hébergée (Atlas). Leur documentation fait apparaître qu'il existe une option de synchronisation possible.
Cet article de décembre 2018 traite de 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/building-ios-and-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: "La synchronisation vous permet de gérer l'état de n'importe quel nombre d'appareils en temps réel à grande échelle sans avoir à gérer d'infrastructure backend."
J'ai considéré 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 les ai utilisés pour envoyer des mises à jour par SMS à partir d'une simple application Web.
[Modifier] J'ai passé du temps avec Realm depuis que j'ai écrit ceci. J'aime la façon dont je n'ai pas à écrire une API pour synchroniser les données entre l'application et le serveur, similaire à Firebase. Les fonctions sans serveur semblent également être très utiles avec ces deux, limitant la quantité de code backend que je dois écrire.
J'adore la flexibilité du magasin de données MongoDB, c'est donc mon choix pour le côté serveur des applications Web et d'autres applications nécessitant une connexion.
J'ai trouvé RESTHeart , 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 à leur tour les transmet vers / depuis MongoDB.
[Modifier] J'ai ajouté des informations sur la façon dont les données sont stockées. Parfois, il est important de savoir combien de travail vous pourriez effectuer pendant le développement et les tests si vous devez modifier et tester les données.
Modifications 2/2019 J'ai expérimenté plusieurs de ces options lors de la conception d'un projet à forte concurrence au cours de la dernière année (2018). Certains d'entre eux mentionnent des limites de concurrence strictes et souples dans leur documentation (Firebase en avait une à 10 000 connexions, je crois, tandis que celle de Twilio était une limite souple qui pouvait être augmentée, selon les discussions avec les deux équipes chez AltConf).
Si vous concevez une application pour des dizaines à des centaines de milliers d'utilisateurs, préparez-vous à faire évoluer le backend de données en conséquence.