Anduvimos indagado por el mundo on line para tener para ti la respuesta a tu dilema, si tienes preguntas deja tu duda y te respondemos sin falta, porque estamos para ayudarte.
Solución:
Esto es lo que he aprendido al determinar la mejor manera de seguir adelante con un par de mis proyectos actuales de aplicaciones.
Almacenamiento asincrónico (antes “integrado” en React Native, ahora se movió por sí solo)
Utilizo AsyncStorage para una aplicación en producción. El almacenamiento permanece local en el dispositivo, no está encriptado (como se menciona en otra respuesta), desaparece si elimina la aplicación, pero debe guardarse como parte de las copias de seguridad de su dispositivo y persiste durante las actualizaciones (tanto las actualizaciones nativas como TestFlight y las actualizaciones de código a través de CodePush ).
Conclusión: almacenamiento local; usted proporciona su propia solución de sincronización / copia de seguridad.
SQLite
Otros proyectos en los que he trabajado han utilizado sqlite3 para el almacenamiento de aplicaciones. Esto le brinda una experiencia similar a SQL, con bases de datos comprimibles que también se pueden transmitir desde y hacia el dispositivo. No he tenido ninguna experiencia en sincronizarlos con un back-end, pero imagino que existen varias bibliotecas. Hay bibliotecas RN para conectarse a SQLite.
Los datos se almacenan en su formato de base de datos tradicional con bases de datos, tablas, keys, índices, etc., todos guardados en el disco en formato binario. El acceso directo a los datos está disponible a través de la línea de comandos o aplicaciones que tienen controladores SQLite.
Conclusión: almacenamiento local; usted proporciona la sincronización y la copia de seguridad.
Firebase
Firebase ofrece, entre otras cosas, una base de datos noSQL en tiempo real junto con un almacén de documentos JSON (como MongoDB) destinado a mantener sincronizados de 1 an un número de clientes. Los documentos hablan de la persistencia sin conexión, pero solo para el código nativo (Swift / Obj-C, Java). La propia opción de JavaScript de Google (“Web”) que utiliza React Native no proporciona una opción de almacenamiento en caché (consulte la actualización del 18/2 a continuación). La biblioteca se escribe asumiendo que se va a conectar un navegador web, por lo que habrá una conexión semipersistente. Probablemente podría escribir un mecanismo de almacenamiento en caché local para complementar las llamadas de almacenamiento de Firebase, o podría escribir un puente entre las bibliotecas nativas y React Native.
Actualización 2/2018
Desde entonces, encontré React Native Firebase, que proporciona una interfaz JavaScript compatible con las bibliotecas nativas de iOS y Android (haciendo lo que Google probablemente podría / debería haber hecho), brindándote todas las ventajas de las bibliotecas nativas con la ventaja de la compatibilidad con React Native. Con la introducción de Google de un almacén de documentos JSON junto a la base de datos en tiempo real, le estoy dando a Firebase un buen segundo vistazo a algunas aplicaciones en tiempo real que planeo construir.
La base de datos en tiempo real se almacena como un árbol similar a JSON que puede editar en el sitio web e importar / exportar de manera bastante simple.
Conclusión: con react-native-firebase, RN obtiene los mismos beneficios que Swift y Java. [/update] Se adapta bien a los dispositivos conectados a la red. Bajo costo para baja utilización. Combina muy bien con otras ofertas de nube de Google. Datos fácilmente visibles y editables desde su interfaz.
Reino
Actualización 4/2020
MongoDB ha adquirido Realm y planea combinarlo con MongoDB Stitch (que se analiza a continuación). Esto parece muy emocionante.
Actualización 9/2020
Habiendo usado Realm vs. Stitch: Las API de Stitch esencialmente permitieron que una aplicación JS (React Native o web) se comunicara directamente con la base de datos de Mongo en lugar de pasar por un servidor API que usted mismo construyó.
Realm estaba destinado a sincronizar partes de la base de datos cada vez que se realizaban cambios.
La combinación de los dos se vuelve un poco confusa. Las API anteriormente conocidas como Stitch todavía funcionan como su consulta tradicional de Mongo y las llamadas de actualización, mientras que las cosas más nuevas de Realm se adjuntan a los objetos en el código y manejan la sincronización por sí mismas … principalmente. Todavía estoy trabajando en la forma correcta de hacer las cosas en un proyecto, que usa SwiftUI, por lo que está un poco fuera de tema. Pero prometedor y ordenado, no obstante.
También un almacén de objetos en tiempo real con sincronización de red automágica. Se promocionan a sí mismos como “el dispositivo primero” y el video de demostración muestra cómo los dispositivos manejan la conectividad de red esporádica o con pérdidas.
Ofrecen una versión gratuita del almacén de objetos que aloja en sus propios servidores o en una solución en la nube como AWS o Azure. También puede crear almacenes en memoria que no persisten con el dispositivo, almacenes de solo dispositivo que no se sincronizan con el servidor, almacenes de servidor de solo lectura y la opción de lectura y escritura completa para la sincronización en uno o más dispositivos. Tienen opciones profesionales y empresariales que cuestan más por adelantado por mes que Firebase.
A diferencia de Firebase, todas las capacidades de Realm son compatibles con React Native y Xamarin, al igual que en las aplicaciones Swift / ObjC / Java (nativas).
Sus datos están vinculados a objetos en su código. Debido a que son objetos definidos, tiene un esquema y el control de versiones es imprescindible para la cordura del código. El acceso directo está disponible a través de las herramientas GUI que proporciona Realm. Los archivos de datos del dispositivo son compatibles con varias plataformas.
Conclusión: Dispositivo primero, sincronización opcional con planes gratuitos y pagos. Todas las funciones son compatibles con React Native. Escalado horizontal más caro que Firebase.
iCloud
Honestamente, no he jugado mucho con este, pero lo haré en un futuro cercano.
Si tiene una aplicación nativa que usa CloudKit, puede usar CloudKit JS para conectarse a los contenedores de su aplicación desde una aplicación web (o, en nuestro caso, React Native). En este escenario, probablemente tendría una aplicación iOS nativa y una aplicación Android React Native.
Al igual que Realm, esto almacena datos localmente y los sincroniza con iCloud cuando es posible. Hay tiendas públicas para su aplicación y tiendas privadas para cada cliente. Los clientes incluso pueden optar por compartir algunas de sus tiendas u objetos con otros usuarios.
No sé qué tan fácil es acceder a los datos sin procesar; los esquemas se pueden configurar en el sitio de Apple.
Conclusión: ideal para aplicaciones dirigidas a Apple.
Couchbase
Gran nombre, muchas grandes empresas detrás de él. Hay una Community Edition y una Enterprise Edition con los costos de soporte estándar.
Tienen un tutorial en su sitio para conectar cosas a React Native. Tampoco he pasado mucho tiempo en este, pero parece ser una alternativa viable a Realm en términos de funcionalidad. No sé qué tan fácil es acceder a sus datos fuera de su aplicación o cualquier API que cree.
[Edit: Found an older link that talks about Couchbase and CouchDB, and CouchDB may be yet another option to consider. The two are historically related but presently completely different products. See this comparison.]
Conclusión: parece tener capacidades similares a las de Realm. Puede ser solo para dispositivo o sincronizado. Necesito probarlo.
MongoDB
Actualización 4/2020
Mongo adquirió Realm y planea combinar MongoDB Stitch (discutido a continuación) con Realm (discutido anteriormente).
Estoy usando este lado del servidor para una parte de la aplicación que usa AsyncStorage localmente. Me gusta que todo se almacene como objetos JSON, lo que hace que la transmisión a los dispositivos cliente sea muy sencilla. En mi caso de uso, se usa como caché entre un proveedor ascendente de datos de guías de TV y mis dispositivos cliente.
Los datos no tienen una estructura rígida, como un esquema, por lo que cada objeto se almacena como un “documento” que se puede buscar, filtrar, etc. attributes u objetos secundarios, lo que permite mucha flexibilidad en la forma en que estructura sus objetos / datos.
No he probado ninguna función de sincronización de cliente a servidor, ni la he utilizado integrada. El código React Native para MongoDB sí existe.
Conclusión: Solución NoSQL solo local, sin opción de sincronización obvia como Realm o Firebase.
Actualización 2/2019
MongoDB tiene un “producto” (o servicio) llamado Stitch. Dado que los clientes (en el sentido de los navegadores web y los teléfonos) no deberían estar hablando directamente con MongoDB (eso se hace mediante el código en su servidor), crearon un front-end sin servidor con el que sus aplicaciones pueden interactuar, en caso de que elija usar su solución alojada (Atlas). Su documentación hace que parezca que existe una posible opción de sincronización.
Este artículo de diciembre de 2018 analiza el uso de React Native, Stitch y MongoDB en una aplicación de muestra, con otras muestras vinculadas en el documento (https://www.mongodb.com/blog/post/building-ios-and-android-apps -con-el-mongodb-stitch-react-native-sdk).
Twilio Sync
Otra opción NoSQL para la sincronización es Twilio’s Sync. Desde su sitio: “Sync le permite administrar el estado en cualquier número de dispositivos en tiempo real a escala sin tener que manejar ninguna infraestructura de backend”.
Vi esto como una alternativa a Firebase para uno de los proyectos antes mencionados, especialmente después de hablar con ambos equipos. También me gustan sus otras herramientas de comunicación y las he usado para enviar mensajes de texto con actualizaciones desde una aplicación web simple.
[Edit] He pasado algún tiempo con Realm desde que escribí esto originalmente. Me gusta cómo no tengo que escribir una API para sincronizar los datos entre la aplicación y el servidor, similar a Firebase. Las funciones sin servidor también parecen ser realmente útiles con estos dos, limitando la cantidad de código de backend que tengo que escribir.
Me encanta la flexibilidad del almacén de datos de MongoDB, por lo que se está convirtiendo en mi elección para el lado del servidor de las aplicaciones basadas en la web y otras aplicaciones que requieren conexión.
Encontré RESTHeart, que crea una API RESTful muy simple y escalable para MongoDB. No debería ser demasiado difícil construir un componente React (Native) que lea y escriba objetos JSON en RESTHeart, que a su vez los pasa a / desde MongoDB.
[Edit] Agregué información sobre cómo se almacenan los datos. A veces, es importante saber cuánto trabajo puede realizar durante el desarrollo y las pruebas si tiene que modificar y probar los datos.
Ediciones 2/2019 Experimenté con varias de estas opciones al diseñar un proyecto de alta concurrencia el año pasado (2018). Algunos de ellos mencionan límites de concurrencia duros y blandos en su documentación (creo que Firebase tenía uno difícil en 10,000 conexiones, mientras que el de Twilio era un límite suave que podría superarse, según las discusiones con ambos equipos en AltConf).
Si está diseñando una aplicación para decenas a cientos de miles de usuarios, esté preparado para escalar el backend de datos en consecuencia.
Rápido y sucio: solo use Redux + react-redux + redux-persist + AsyncStorage para react-native.
Se adapta casi a la perfección al mundo nativo de React y funciona a la perfección tanto para Android como para iOS. Además, hay una comunidad sólida a su alrededor y mucha información.
Para ver un ejemplo práctico, consulte F8App de Facebook.
¿Cuáles son las diferentes opciones para la persistencia de datos?
Con react native, probablemente desee utilizar redux y redux-persist. Puede utilizar varios motores de almacenamiento. AsyncStorage y redux-persist-filesystem-storage son las opciones para RN.
Existen otras opciones como Firebase o Realm, pero nunca las usé en un proyecto de RN.
Para cada uno, ¿cuáles son los límites de esa persistencia (es decir, cuándo los datos ya no están disponibles)? Por ejemplo: al cerrar la aplicación, reiniciar el teléfono, etc.
Usando redux + redux-persist puede definir qué es persistente y qué no. Cuando no persiste, los datos existen mientras la aplicación se está ejecutando. Cuando persiste, los datos persisten entre las ejecuciones de la aplicación (cerrar, abrir, reiniciar el teléfono, etc.).
AsyncStorage tiene un límite predeterminado de 6 MB en Android. Es posible configurar un límite mayor (en código Java) o usar redux-persist-filesystem-storage como motor de almacenamiento para Android.
Para cada uno, ¿existen diferencias (además de la configuración general) entre la implementación en iOS y Android?
Usando redux + redux-persist + AsyncStorage, la configuración es exactamente la misma en Android e iOS.
¿Cómo se comparan las opciones para acceder a datos sin conexión? (¿o cómo se maneja normalmente el acceso sin conexión?)
Usando redux, el acceso fuera de línea es casi automático gracias a sus partes de diseño (creadores de acciones y reductores).
Todos los datos que obtuviste y almacenaste están disponibles, puedes almacenar fácilmente datos adicionales para indicar el estado (obtención, éxito, error) y la hora en que se obtuvieron. Normalmente, solicitar una recuperación no invalida los datos más antiguos y sus componentes simplemente se actualizan cuando se reciben nuevos datos.
Lo mismo se aplica en la otra dirección. Puede almacenar los datos que está enviando al servidor y que aún están pendientes y manejarlos en consecuencia.
¿Hay otras consideraciones que deba tener en cuenta?
React promueve una forma reactiva de crear aplicaciones y Redux encaja muy bien en ella. Debería probarlo antes de usar una opción que usaría en su aplicación habitual de Android o iOS. Además, encontrará muchos más documentos y ayuda para ellos.
Las personas de arriba toman las notas correctas para el almacenamiento, aunque si también necesita considerar cualquier dato de PII que deba almacenarse, también puede guardarlo en el llavero usando algo como https://github.com/oblador/react-native-keychain ya que ASyncStorage no está encriptado. Se puede aplicar como parte de la configuración de persistencia en algo como redux-persist.
Eres capaz de confirmar nuestra publicación ejecutando un comentario y valorándolo te damos las gracias.