Які мої варіанти зберігання даних при використанні React Native? (iOS та Android) [закрито]

Я все ще є новим у світі React Native, і взагалі в мобільному / рідному світі, і я знаходжу документацію, якої бракує, коли мова йде про збереження даних.

Які мої варіанти зберігання даних у React Native та наслідки кожного типу? Наприклад, я бачу, що є локальне зберігання та асинхронне зберігання, але потім я також бачу такі речі, як Realm, і я плутаюся, як все це працюватиме із зовнішньою базою даних.

Я спеціально хочу знати:

• Які існують варіанти збереження даних?
• Які межі такої стійкості є для кожного (тобто коли дані більше не доступні)? Наприклад: при закритті програми, перезавантаженні телефону тощо.
• Чи існують відмінності (крім загальної настройки) між реалізацією в iOS проти Android?
• Як параметри порівняння доступу до даних офлайн? (або як зазвичай обробляється доступ в автономному режимі?)
• Чи варто мати на увазі якісь інші міркування?

Спасибі за вашу допомогу!

Ось що я дізнався, коли визначаю найкращий спосіб просунутися вперед через пару моїх поточних проектів додатків.

Async Storage ("вбудований" для React Native)

Я використовую AsyncStorage для додатка у виробництві. Зберігання залишається локальним для пристрою, незашифровано (як згадується в іншій відповіді), відходить, якщо ви видалите додаток, але його слід зберегти як частину резервного копіювання вашого пристрою та зберігається під час оновлення (обидва нативні оновлення ala TestFlight та оновлення коду за допомогою CodePush ).

Висновок: Місцеве зберігання; Ви надаєте власне рішення для синхронізації / резервного копіювання.

SQLite

Інші проекти, над якими я працював, використовували sqlite3 для зберігання додатків. Це дає вам досвід, схожий на SQL, зі стислими базами даних, які також можуть передаватися на пристрій і з нього. У мене не було жодного досвіду синхронізації їх із зворотним боком, але я думаю, що існують різні бібліотеки. Існують бібліотеки RN для підключення до SQLite.

Дані зберігаються у вашому традиційному форматі бази даних з базами даних, таблицями, ключами, індексами тощо, всі збережені на диску у двійковому форматі. Прямий доступ до даних доступний через командний рядок або програми, які мають драйвери SQLite.

Висновок: Місцеве зберігання; Ви постачаєте синхронізацію та резервну копію.

Firebase

Firebase пропонує, крім іншого, базу даних noSQL у реальному часі разом із сховищем документів JSON (як MongoDB), призначеним для синхронізації від 1 до n кількості клієнтів. Документи говорять про офлайн-стійкість, але лише для рідного коду (Swift / Obj-C, Java). Власна опція JavaScript ("Веб"), яку використовує React Native, не забезпечує опцію зберігання в кешеному пам’яті (див. Оновлення 2/18 нижче). Бібліотека записана з припущенням, що веб-браузер буде підключатися, і тому буде напівстійке з'єднання. Ви, ймовірно, можете написати локальний механізм кешування для доповнення викликів на сховище Firebase, або ви можете написати міст між рідними бібліотеками та React Native.

Оновлення 2/2018 З тих пір я знайшов React Native Firebase, який забезпечує сумісний інтерфейс JavaScript для рідних бібліотек iOS та Android (роблячи те, що Google, мабуть, міг / повинен був зробити), надаючи всім смаком рідних бібліотек із бонусом React Рідна підтримка. Завдяки впровадженню Google сховища документів JSON поруч із базою даних у реальному часі я даю Firebase гарний другий пошук деяких програм у реальному часі, які я планую створити.

База даних у реальному часі зберігається як дерево, схоже на JSON, яке ви можете редагувати на веб-сайті та імпортувати / експортувати досить просто.

Висновок: Завдяки реакції-native-firebase RN отримує ті ж переваги, що і Swift та Java. [/ update] Масштаби добре для підключених до мережі пристроїв. Низька вартість за низького використання. Добре поєднується з іншими пропозиціями хмари Google. Дані легко помітні та редаговані з їх інтерфейсу.

Царство

Оновлення 4/2020 MongoDB придбало Realm і планує поєднувати його з MongoDB Stitch (обговорюється нижче). Це виглядає дуже захоплююче .

Також магазин об'єктів у реальному часі з автоматичною мережевою синхронізацією. Вони рекламують себе як "пристрій спочатку", а демонстраційне відео показує, як пристрої обробляють спорадичну або втрату мережевого підключення.

Вони пропонують безкоштовну версію об’єктного магазину, який розміщується на ваших власних серверах або в хмарному рішенні, наприклад AWS або Azure. Ви також можете створити сховища пам’яті, які не зберігаються з пристроєм, сховища лише для пристроїв, які не синхронізуються з сервером, сервери, що зберігаються лише для читання, і повний параметр для читання-запису для синхронізації на одному або декількох пристроях. У них є професійні та корпоративні варіанти, які коштують дорожче за передній місяць, ніж Firebase.

На відміну від Firebase, всі можливості Realm підтримуються в React Native та Xamarin, як і в Swift / ObjC / Java (рідні) додатки.

Ваші дані прив’язані до об'єктів у вашому коді. Оскільки вони є визначеними об'єктами, у вас є схема, і контроль версій є обов'язковим для безпечності коду. Прямий доступ доступний через інструменти GUI, які надає Realm. Файли даних на пристрої сумісні між платформами.

Висновок: Спочатку пристрій, додаткова синхронізація з безкоштовними та платними планами. Усі функції, які підтримуються в React Native. Горизонтальне масштабування дорожче, ніж Firebase.

iCloud

Я, чесно кажучи, не дуже багато грав з цим, але буду робити це найближчим часом.

Якщо у вас є вбудована програма, яка використовує CloudKit, ви можете використовувати CloudKit JS для підключення до контейнерів вашого додатка через веб-додаток (або, у нашому випадку, React Native). У цьому випадку ви, мабуть, матимуть нативну програму для iOS та додаток React Native Android.

Як і Realm, і цей зберігає дані локально та синхронізує їх з iCloud, коли це можливо. Існують державні магазини для вашої програми та приватні магазини для кожного клієнта. Клієнти можуть навіть вирішити поділитися деякими своїми магазинами чи предметами з іншими користувачами.

Я не знаю, як легко отримати доступ до необроблених даних; схеми можна налаштувати на сайті Apple.

Висновок: чудово підходить для програм, орієнтованих на Apple.

Couchbase

Велике ім'я, за ним багато великих компаній. Є Community Edition та Enterprise Edition зі стандартними витратами на підтримку.

На їхньому сайті є підручник для підключення речей до React Native. Я також не витратив багато часу на цей, але це виглядає життєздатною альтернативою Realm з точки зору функціональності. Я не знаю, як легко отримати доступ до своїх даних за межами програми або будь-яких API, який ви будуєте.

[Редагувати: Знайдено старішу посилання, яка розповідає про Couchbase та CouchDB, а CouchDB може бути ще одним варіантом розгляду. Ці два історично пов'язані, але зараз абсолютно різні продукти. Дивіться це порівняння .]

Висновок: Схоже, має подібні можливості, як Realm. Може бути лише пристроєм або синхронізовано. Мені потрібно спробувати.

MongoDB

Оновлення 4/2020

Mongo придбав Realm і планує поєднувати MongoDB Stitch (обговорюється нижче) з Realm (обговорювалося вище).

Я використовую цю сторону сервера для частини програми, яка локально використовує AsyncStorage. Мені подобається, що все зберігається як об’єкти JSON, що робить передачу на клієнтські пристрої дуже простою. У моєму випадку він використовується як кеш-пам'ять між постачальником даних телевізійних путівників і моїми клієнтськими пристроями.

Для даних немає жорсткої структури, як схема, тому кожен об'єкт зберігається як "документ", який легко шукати, фільтрувати тощо. Подібні об'єкти JSON можуть мати додаткові (але різні) атрибути або дочірні об'єкти, що дозволяє мати велика гнучкість у структурі об'єктів / даних.

Я не пробував жодної функції синхронізації з клієнтом на сервері, і не використовував її вбудовану. Реактивний кодовий код для MongoDB існує.

Висновок: лише локальне рішення NoSQL, відсутність очевидних параметрів синхронізації, таких як Realm або Firebase.

Оновлення 2/2019

У MongoDB є "продукт" (або послуга) під назвою Stitch. Оскільки клієнти (у сенсі веб-браузерів та телефонів) не повинні спілкуватися безпосередньо з MongoDB (це робиться за допомогою коду на вашому сервері), вони створили фронт-сервер без сервера, з яким ваші програми можуть взаємодіяти, якщо ви вирішите використовувати їх прийняте рішення (Атлас). З їх документації видно, що можливий варіант синхронізації.

У цьому описі з грудня 2018 року обговорюється використання React Native, Stitch та MongoDB у зразковому додатку з іншими зразками, пов’язаними в документі ( https://www.mongodb.com/blog/post/building-ios-and-android-apps -with-the-mongodb-stitch-react-native-sdk ).

Twilio Sync

Ще один варіант NoSQL для синхронізації - це синхронізація Twilio. З їх сайту: "Синхронізація дозволяє керувати станом на будь-якій кількості пристроїв у режимі реального часу в масштабі, не обробляючи жодної інфраструктури."

Я розглядав це як альтернативу Firebase для одного з вищезгаданих проектів, особливо після розмови з обома командами. Мені також подобаються інші їх засоби комунікації, і я використовував їх для надсилання текстових оновлень із простого веб-додатка.

[Редагувати] Я провів деякий час з Realm, оскільки спочатку написав це. Мені подобається, як мені не потрібно писати API, щоб синхронізувати дані між додатком та сервером, подібно до Firebase. Функції без сервера також виглядають дуже корисними для цих двох, обмежуючи кількість резервного коду, який я маю написати.

Мені подобається гнучкість зберігання даних MongoDB, тому це стає моїм вибором для серверної частини веб-додатків та інших програм, необхідних для підключення.

Я знайшов RESTHeart , який створює дуже простий, масштабований API RESTful для MongoDB. Створювати компонент React (Native), який читає і записує JSON-об'єкти в RESTHeart, не повинно бути надто важким, що, в свою чергу, передає їх в / з MongoDB.

[Редагувати] Я додав інформацію про збереження даних. Іноді важливо знати, якою роботою ви можете займатися під час розробки та тестування, якщо вам доведеться налаштувати та перевірити дані.

Зміни 2/2019 Я експериментував з декількома з цих варіантів, розробляючи проект з високою конкурентоспроможністю минулого року (2018). Деякі з них в своїй документації згадують жорсткі та м'які обмеження конкурентоспроможності (я вважаю, Firebase мав жорстку межу на 10000 з'єднань, тоді як Twilio - це м'який ліміт, який можна було зіткнути, згідно з дискусіями з обома командами в AltConf).

Якщо ви розробляєте додаток для десятків до сотень тисяч користувачів, будьте готові відповідно масштабувати дані.

Швидкий і брудний: просто використовувати Redux + реагувати-перевождь + перевождь-упиратися + AsyncStorage для реакції рідний.

Він майже ідеально вписується у реагуючий рідний світ та працює як шарм і для андроїда та для ios. Також навколо нього є міцна спільнота та велика кількість інформації.

Для робочого прикладу дивіться F8App від Facebook.

Які існують варіанти збереження даних?

З реагуванням нативної мови, ви, ймовірно, хочете скористатися функцією redux та redux. Він може використовувати декілька двигунів зберігання даних. AsyncStorage і redux-persist-fileystem-storage - це параметри для RN.

Є й інші варіанти, такі як Firebase або Realm, але я ніколи не використовував їх у проекті RN.

Які межі такої стійкості є для кожного (тобто коли дані більше не доступні)? Наприклад: при закритті програми, перезавантаженні телефону тощо.

Використовуючи redux + redux-persist, можна визначити, що зберігається, а що ні. Якщо не зберігається, дані існують під час роботи програми. Якщо зберігається, дані зберігаються між програмами (закрити, відкрити, перезапустити телефон тощо).

На Android для AsyncStorage встановлено ліміт 6MB за замовчуванням. Можна налаштувати більший ліміт (для коду Java) або використовувати резервно-збережену файлову систему-сховище як двигун зберігання для Android.

Чи існують відмінності (крім загальної настройки) між реалізацією в iOS проти Android?

Використання redux + redux-persist + AsyncStorage налаштування точно однакові для Android та iOS.

Як параметри порівняння доступу до даних офлайн? (або як зазвичай обробляється доступ в автономному режимі?)

Використовуючи функцію redux, офлайн-доступ майже автоматичний завдяки своїм конструктивним частинам (створювачам дій та редукторам).

Усі дані, які ви отримували та зберігали, доступні, ви можете легко зберігати додаткові дані, щоб вказати стан (отримання, успіх, помилка) та час його отримання. Зазвичай запит на отримання не приводить до недійсності старіших даних, а ваші компоненти просто оновлюються, коли отримуються нові дані.

Те саме стосується і в іншому напрямку. Ви можете зберігати дані, які ви надсилаєте на сервер, і які все ще перебувають у стані очікування та обробляти їх відповідно.

Чи варто мати на увазі якісь інші міркування?

React рекламує реактивний спосіб створення додатків і Redux дуже добре підходить для цього. Спробуйте його спробувати перед тим, як просто скористатися опцією, яку ви використовували б у звичайному додатку для Android або iOS. Також ви знайдете набагато більше документів та допомогу для них.

Люди вище звертаються до правильних нотаток для зберігання, хоча якщо вам також потрібно врахувати будь-які дані PII, які потрібно зберігати, ви також можете зберігати в брелок, використовуючи щось на зразок https://github.com/oblador/react-native-keychain оскільки ASyncStorage незашифрований. Він може бути застосований як частина консистенції персистування у чомусь схожому на відновлювальному.

ви можете використовувати сховище синхронізації, яке простіше використовувати, ніж сховище async. ця бібліотека чудова, що використовує сховище async для збереження даних асинхронно і використовує пам'ять для завантаження та збереження даних миттєво синхронно, тому ми зберігаємо асинхронізацію даних у пам'яті та використовуємо в синхронізації додатків, тому це чудово.

import SyncStorage from 'sync-storage';

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

ви можете використовувати Realm або Sqlite, якщо ви хочете керувати складними типами даних.

В іншому випадку перейдіть з вбудованою реакцією на рідну асинтографію

Нам не потрібно редукції, ми можемо просто використовувати скорочення для збереження.

react-redux + AsyncStorage = скорочення-збереження

тому всередині createsotre-файлу просто додайте ці рядки

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

це буде оновлювати AsyncStorage щоразу, коли в магазині redux буде якісь зміни.

Потім завантажте магазин, який перетворив json. коли-небудь програма завантажується. і знову встановити магазин.

Оскільки функція redux-persist створює проблеми при використанні вікс-реакторів-навігації. Якщо це так, то я вважаю за краще використовувати простий редукс з вищевказаною функцією абонента