¿Cuáles son mis opciones para almacenar datos cuando uso React Native? (iOS y Android) [cerrado]

Todavía soy nuevo en el mundo React Native, y en general también en el mundo móvil / nativo, y la documentación me falta un poco en lo que respecta a la persistencia de datos.

¿Cuáles son mis opciones para almacenar datos en React Native y las implicaciones de cada tipo? Por ejemplo, veo que hay almacenamiento local y almacenamiento asíncrono, pero también veo cosas como Realm, y estoy confundido sobre cómo funcionaría todo esto con una base de datos externa.

Específicamente quiero saber:

• ¿Cuáles son las diferentes opciones para la persistencia de datos?
• Para cada uno, ¿cuáles son los límites de esa persistencia (es decir, cuándo ya no están disponibles los datos)? Por ejemplo: al cerrar la aplicación, reiniciar el teléfono, etc.
• Para cada uno, ¿hay diferencias (aparte de la configuración general) entre la implementación en iOS vs Android?
• ¿Cómo se comparan las opciones para acceder a los datos sin conexión? (¿o cómo se maneja normalmente el acceso sin conexión?)
• ¿Hay alguna otra consideración que deba tener en cuenta?

¡Gracias por tu ayuda!

Esto es lo que aprendí al determinar la mejor manera de avanzar con un par de mis proyectos de aplicaciones actuales.

Almacenamiento asíncrono ("incorporado" para reaccionar nativo)

Yo uso 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 / respaldo.

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, claves, í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; 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 a n número de clientes. Los documentos hablan sobre la persistencia fuera de línea, 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 2/18 a continuación). La biblioteca está escrita con el supuesto de que un navegador web se va a conectar, 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 de JavaScript compatible con las bibliotecas nativas de iOS y Android (haciendo lo que Google probablemente podría / debió haber hecho), ofreciéndole todas las ventajas de las bibliotecas nativas con la ventaja de React Apoyo nativo 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 una buena segunda mirada para 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. [/ actualización] Escala bien para dispositivos conectados a la red. Bajo costo por baja utilización. Combina muy bien con otras ofertas en la nube de Google. Datos fácilmente visibles y editables desde su interfaz.

Reino

Actualización 4/2020 MongoDB ha adquirido Realm y está planeando combinarlo con MongoDB Stitch (discutido a continuación). Esto se ve muy emocionante .

También una tienda de objetos en tiempo real con sincronización de red automática. Se promocionan a sí mismos como "dispositivo primero" y el video de demostración muestra cómo los dispositivos manejan la conectividad de red esporádica o con pérdida.

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 persistan con el dispositivo, almacenes solo para dispositivos que no se sincronizan con el servidor, almacenes de servidor de solo lectura y la opción completa de lectura y escritura para la sincronización en uno o más dispositivos. Tienen opciones profesionales y empresariales que cuestan más por mes que Firebase.

A diferencia de Firebase, todas las capacidades de Realm son compatibles con React Native y Xamarin, al igual que 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 Realm proporciona. Los archivos de datos en el dispositivo son compatibles con todas las plataformas.

Conclusión: dispositivo primero, sincronización opcional con planes gratuitos y pagos. Todas las funciones compatibles con React Native. Escalado horizontal más costoso que Firebase.

iCloud

Sinceramente, no he jugado mucho con este, pero lo haré en el 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 React Native Android.

Al igual que Realm, 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 elegir compartir algunas de sus tiendas u objetos con otros usuarios.

No sé lo fácil que 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 compañías detrás de él. Hay una edición comunitaria y una edición empresarial con los costos de soporte estándar.

Tienen un tutorial en su sitio para conectar cosas a React Native. Tampoco he pasado mucho tiempo con este, pero parece ser una alternativa viable a Realm en términos de funcionalidad. No sé lo fácil que es acceder a sus datos fuera de su aplicación o de cualquier API que cree.

[Editar: Encontré un enlace anterior que habla sobre Couchbase y CouchDB, y CouchDB puede ser otra opción a tener en cuenta. Los dos están históricamente relacionados, pero actualmente son productos completamente diferentes. Ver esta comparación .]

Conclusión: parece tener capacidades similares a Realm. Puede ser solo dispositivo o sincronizado. Necesito probarlo.

MongoDB

Actualización 4/2020

Mongo adquirió Realm y planea combinar MongoDB Stitch (discutido más abajo) con Realm (discutido arriba).

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 del cliente sea muy sencilla. En mi caso de uso, se usa como caché entre un proveedor de datos de guía 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. Mucha flexibilidad en cómo estructurar sus objetos / datos.

No he probado ninguna función de sincronización de cliente a servidor, ni la he usado integrada. React El código nativo para MongoDB 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 hablar directamente con MongoDB (esto se hace mediante un código en su servidor), crearon un front-end sin servidor con el que sus aplicaciones pueden interactuar, si decide usar su solución alojada (Atlas). Su documentación hace parecer que existe una posible opción de sincronización.

Este informe 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 -with-the-mongodb-stitch-react-native-sdk ).

Twilio Sync

Otra opción NoSQL para sincronización es la sincronización de Twilio. 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 back-end".

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 actualizaciones de mensajes de texto desde una aplicación web simple.

[Editar] 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 estas dos, limitando la cantidad de código de fondo que tengo que escribir.

Me encanta la flexibilidad del almacén de datos MongoDB, por lo que se está convirtiendo en mi elección para el lado del servidor de aplicaciones basadas en 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.

[Editar] 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 ajustar 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 rígidos y blandos en su documentación (Firebase tenía uno duro con 10,000 conexiones, creo, mientras que Twilio era un límite blando que podría ser superado, según las discusiones con ambos equipos en AltConf).

Si está diseñando una aplicación para decenas a cientos de miles de usuarios, prepárese 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 perfectamente al mundo nativo de reacción y funciona de maravilla tanto para Android como para iOS. Además, hay una comunidad sólida a su alrededor y mucha información.

Para un ejemplo de trabajo, vea la F8App de Facebook.

¿Cuáles son las diferentes opciones para la persistencia de datos?

Con react native, probablemente quieras usar redux y redux-persist. Puede usar múltiples motores de almacenamiento. AsyncStorage y redux-persist-filesystem-storage son las opciones para RN.

Hay otras opciones como Firebase o Realm, pero nunca las usé en un proyecto RN.

Para cada uno, ¿cuáles son los límites de esa persistencia (es decir, cuándo ya no están disponibles los datos)? 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, existen datos mientras se ejecuta la aplicación. 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, ¿hay diferencias (aparte de la configuración general) entre la implementación en iOS vs 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 los 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 acción y reductores).

Todos los datos que obtuvo y almacenó están disponibles, puede almacenar fácilmente datos adicionales para indicar el estado (recuperación, éxito, error) y la hora en que se recuperaron. Normalmente, solicitar una búsqueda 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 alguna otra consideración que deba tener en cuenta?

React promueve una forma reactiva de crear aplicaciones y Redux encaja muy bien en él. Deberías probarlo antes de usar una opción que usarías en tu aplicación normal de Android o iOS. Además, encontrará muchos más documentos y ayuda para ellos.

Las personas anteriores tocan las notas correctas para el almacenamiento, aunque si también necesita considerar cualquier información PII que deba almacenarse, también puede esconderse 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.

puede usar el almacenamiento sincronizado que es más fácil de usar que el almacenamiento asíncrono. esta biblioteca es excelente, ya que utiliza almacenamiento asíncrono para guardar datos de forma asincrónica y usa memoria para cargar y guardar datos instantáneamente de forma síncrona, por lo que guardamos los datos asíncronos en la memoria y los utilizamos en la sincronización de aplicaciones, por lo que es genial.

import SyncStorage from 'sync-storage';

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

puede usar Realm o Sqlite si desea administrar tipos de datos complejos.

De lo contrario ir con incorporado asynstorage nativo reaccionar

No necesitamos redux-persist, simplemente podemos usar redux para persistencia.

react-redux + AsyncStorage = redux-persist

así que dentro del archivo createotre simplemente agrega estas líneas

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

esto actualizará AsyncStorage cada vez que haya algunos cambios en la tienda redux.

Luego cargue la tienda convertida json. cuando alguna vez se carga la aplicación. y configurar la tienda de nuevo.

Porque redux-persist crea problemas al usar wix react-native-navigation. Si ese es el caso, prefiero usar redux simple con la función de suscriptor anterior