android - run - react native npm
¿Cuáles son mis opciones para almacenar datos cuando uso React Native?(iOS y Android) (6)
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 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), brindándote todas las ventajas de las bibliotecas nativas con la bonificación de React Native support. Con la introducción de Google de una tienda 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
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 en 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
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. Objetos JSON similares podrían tener atributos adicionales (pero diferentes) u objetos secundarios, lo que permite un 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 hay una posible opción de sincronización.
Este informe de diciembre de 2018 trata sobre 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".
Lo vi 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.
[/Actualizar]
[Editar] He pasado algún tiempo con Realm desde que originalmente escribí esto. 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 de 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.
[Actualización 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 en 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.
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!
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 dado que ASyncStorage no está encriptado. Se puede aplicar como parte de la configuración de persistencia en algo como redux-persist.
No necesitamos redux-persist simplemente podemos usar redux para persistencia.
react-redux + AsyncStorage = redux-persist
así que dentro del archivo createotre simplemente agregue 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
Rápido y sucio: solo use Redux + react-redux + redux-persist AsyncStorage + 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, los datos existen 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 recuperados y almacenados 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ía probarlo antes de usar una opción que usaría en su aplicación normal de Android o iOS. Además, encontrará muchos más documentos y ayuda para ellos.
puede usar Realm o Sqlite si desea administrar tipos de datos complejos.
De lo contrario ir con incorporado asynstorage nativo reaccionar
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 sincrónicamente, 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''