Oto, czego się nauczyłem, gdy określam najlepszy sposób na przejście do kilku moich bieżących projektów aplikacji.
Pamięć asynchroniczna („wbudowana” w React Native)
Używam AsyncStorage do aplikacji w produkcji. Pamięć pozostaje lokalna dla urządzenia, jest nieszyfrowana (jak wspomniano w innej odpowiedzi), znika, jeśli usuwasz aplikację, ale powinna być zapisywana jako część kopii zapasowych urządzenia i utrzymuje się podczas aktualizacji (zarówno aktualizacje natywne ala TestFlight, jak i aktualizacje kodu za pomocą CodePush ).
Wniosek: przechowywanie lokalne; zapewniasz własne rozwiązanie synchronizacji / tworzenia kopii zapasowych.
SQLite
Inne projekty, nad którymi pracowałem, wykorzystywały sqlite3 do przechowywania aplikacji. Daje to wrażenia podobne do SQL, dzięki kompresyjnym bazom danych, które mogą być również przesyłane do i z urządzenia. Nie miałem doświadczenia w synchronizowaniu ich z zapleczem, ale wyobrażam sobie, że istnieją różne biblioteki. Istnieją biblioteki RN do łączenia się z SQLite.
Dane są przechowywane w tradycyjnym formacie bazy danych z bazami danych, tabelami, kluczami, indeksami itp. Zapisanymi na dysku w formacie binarnym. Bezpośredni dostęp do danych jest możliwy za pośrednictwem wiersza polecenia lub aplikacji ze sterownikami SQLite.
Wniosek: przechowywanie lokalne; zapewniasz synchronizację i kopię zapasową.
Firebase
Firebase oferuje między innymi bazę danych noSQL w czasie rzeczywistym oraz magazyn dokumentów JSON (taki jak MongoDB) przeznaczony do synchronizacji od 1 do n liczby klientów. Dokumenty mówią o trwałości offline, ale tylko w przypadku kodu natywnego (Swift / Obj-C, Java). Własna opcja Google JavaScript („Internet”), która jest używana przez React Native, nie zapewnia opcji pamięci podręcznej (patrz aktualizacja 2/18 poniżej). Biblioteka jest napisana przy założeniu, że przeglądarka internetowa będzie się łączyła, a więc będzie połączenie półtrwałe. Prawdopodobnie możesz napisać lokalny mechanizm buforowania w celu uzupełnienia wywołań pamięci Firebase, lub możesz napisać pomost między bibliotekami natywnymi a React Native.
Aktualizacja 2/2018
Od tamtej pory znalazłem React Native Firebase, który zapewnia kompatybilny interfejs JavaScript dla rodzimych bibliotek iOS i Android (robiąc to, co Google prawdopodobnie powinien / powinien zrobić), dając ci wszystkie zalety rodzimych bibliotek z premią React Natywne wsparcie. Wraz z wprowadzeniem przez Google magazynu dokumentów JSON obok bazy danych w czasie rzeczywistym, daję Firebase dobry wgląd w niektóre aplikacje w czasie rzeczywistym, które planuję zbudować.
Baza danych w czasie rzeczywistym jest przechowywana jako drzewo podobne do JSON, które można edytować na stronie internetowej i importować / eksportować po prostu.
Wniosek: RN z rodzajem React-Native-Firebase ma takie same korzyści jak Swift i Java. [/ update] Dobrze skaluje się dla urządzeń podłączonych do sieci. Niski koszt niskiego wykorzystania. Ładnie łączy się z innymi ofertami chmurowymi Google. Dane łatwo widoczne i edytowalne z poziomu interfejsu.
Królestwo
Aktualizacja 4/2020
MongoDB nabył Realm i planuje połączyć go ze ściegiem MongoDB (omówionym poniżej). To wygląda bardzo ekscytująco .
Również magazyn obiektów w czasie rzeczywistym z automatyczną synchronizacją sieci. Występują jako „najpierw urządzenia”, a film demonstracyjny pokazuje, jak urządzenia radzą sobie ze sporadyczną lub utratą łączności z siecią.
Oferują bezpłatną wersję magazynu obiektów, który hostujesz na własnych serwerach lub w rozwiązaniu chmurowym, takim jak AWS lub Azure. Można także tworzyć magazyny w pamięci, które nie utrzymują się na urządzeniu, sklepy tylko dla urządzeń, które nie synchronizują się z serwerem, magazyny serwerów tylko do odczytu oraz pełną opcję odczytu i zapisu do synchronizacji na jednym lub większej liczbie urządzeń. Mają opcje profesjonalne i dla przedsiębiorstw, które kosztują z góry więcej miesięcznie niż Firebase.
W przeciwieństwie do Firebase wszystkie możliwości Realm są obsługiwane w React Native i Xamarin, podobnie jak w aplikacjach Swift / ObjC / Java (natywnych).
Twoje dane są powiązane z obiektami w kodzie. Ponieważ są to obiekty zdefiniowane, masz schemat, a kontrola wersji jest niezbędna dla zachowania poprawności kodu. Bezpośredni dostęp jest dostępny za pośrednictwem narzędzi GUI, które zapewnia Realm. Pliki danych na urządzeniu są kompatybilne z wieloma platformami.
Wniosek: najpierw urządzenie, opcjonalna synchronizacja z planami bezpłatnymi i płatnymi. Wszystkie funkcje obsługiwane w React Native. Skalowanie w poziomie jest droższe niż Firebase.
iCloud
Szczerze mówiąc, nie grałem dużo z tym, ale zrobię to w najbliższej przyszłości.
Jeśli masz natywną aplikację korzystającą z CloudKit, możesz użyć CloudKit JS do łączenia się z kontenerami aplikacji z aplikacji internetowej (lub, w naszym przypadku, React Native). W tym scenariuszu prawdopodobnie miałbyś natywną aplikację na iOS i aplikację React Native na Androida.
Podobnie jak Realm, przechowuje dane lokalnie i synchronizuje je z iCloud, jeśli to możliwe. Istnieją publiczne sklepy z aplikacjami i prywatne sklepy dla każdego klienta. Klienci mogą nawet udostępniać niektóre swoje sklepy lub obiekty innym użytkownikom.
Nie wiem, jak łatwo jest uzyskać dostęp do surowych danych; schematy można skonfigurować na stronie Apple.
Wniosek: doskonały do aplikacji ukierunkowanych na Apple.
Kanapa
Wielkie nazwisko, za tym stoi wiele dużych firm. Istnieje edycja Community Edition i Enterprise Edition ze standardowymi kosztami wsparcia.
Na swojej stronie znajduje się samouczek dotyczący podłączania React Native. Nie spędziłem też dużo czasu na tym, ale wygląda na to, że jest realną alternatywą dla Realm pod względem funkcjonalności. Nie wiem, jak łatwo można uzyskać dostęp do danych poza aplikacją lub tworzonymi interfejsami API.
[Edytuj: Znaleziono starszy link, który mówi o Couchbase i CouchDB, a CouchDB może być jeszcze jedną opcją do rozważenia. Oba są historycznie powiązane, ale obecnie zupełnie różne produkty. Zobacz to porównanie .]
Wniosek: Wygląda na to, że ma podobne możliwości jak Królestwo. Może być tylko na urządzeniu lub zsynchronizowany. Muszę to wypróbować.
MongoDB
Aktualizacja 4/2020
Mongo nabyło Realm i planuje połączyć ścieg MongoDB (omówiony poniżej) z Realm (omówiony powyżej).
Korzystam z tej strony serwera dla części aplikacji, która używa AsyncStorage lokalnie. Podoba mi się, że wszystko jest przechowywane jako obiekty JSON, dzięki czemu transmisja do urządzeń klienckich jest bardzo prosta. W moim przypadku jest on używany jako pamięć podręczna między dostawcą danych przewodnika telewizyjnego a urządzeniami klienckimi.
Dane nie mają twardej struktury, takiej jak schemat, więc każdy obiekt jest przechowywany jako „dokument”, który można łatwo przeszukiwać, filtrować itp. Podobne obiekty JSON mogą mieć dodatkowe (ale różne) atrybuty lub obiekty potomne, co pozwala na duża elastyczność w strukturze obiektów / danych.
Nie próbowałem żadnych funkcji synchronizacji między klientem a serwerem ani nie korzystałem z niego wbudowanego. React Istnieje natywny kod MongoDB.
Wniosek: tylko lokalne rozwiązanie NoSQL, brak oczywistej opcji synchronizacji, takiej jak Realm lub Firebase.
Aktualizacja 2/2019
MongoDB ma „produkt” (lub usługę) o nazwie Stitch. Ponieważ klienci (w znaczeniu przeglądarek internetowych i telefonów) nie powinni rozmawiać bezpośrednio z MongoDB (odbywa się to za pomocą kodu na serwerze), stworzyli bezserwerowy interfejs, z którym mogą współpracować Twoje aplikacje, gdybyś zdecydował się użyć ich rozwiązanie hostowane (Atlas). Z ich dokumentacji wynika, że istnieje możliwa opcja synchronizacji.
W tym piśmie z grudnia 2018 r. Omówiono używanie React Native, Stitch i MongoDB w przykładowej aplikacji, a inne próbki są połączone w dokumencie ( https://www.mongodb.com/blog/post/building-ios-and-android-apps -with-the-mongodb-stitch-reag-native-sdk ).
Twilio Sync
Inną opcją synchronizacji NoSQL jest Synchronizacja Twilio. Z ich witryny: „Synchronizacja pozwala zarządzać stanem na dowolnej liczbie urządzeń w czasie rzeczywistym na dużą skalę bez konieczności obsługi jakiejkolwiek infrastruktury zaplecza”.
Patrzyłem na to jako alternatywę dla Firebase dla jednego z wyżej wymienionych projektów, szczególnie po rozmowie z obiema drużynami. Podobają mi się również inne narzędzia komunikacyjne i wykorzystałem je do aktualizacji SMS-ów z prostej aplikacji internetowej.
[Edytuj] Spędziłem trochę czasu z Realm odkąd to napisałem. Podoba mi się to, że nie muszę pisać interfejsu API w celu synchronizacji danych między aplikacją a serwerem, podobnie jak Firebase. Funkcje bezserwerowe również wydają się być bardzo pomocne w tych dwóch przypadkach, ograniczając ilość kodu zaplecza, który muszę napisać.
Uwielbiam elastyczność magazynu danych MongoDB, dlatego staje się moim wyborem po stronie serwera aplikacji internetowych i innych aplikacji wymagających połączenia.
Znalazłem RESTHeart , który tworzy bardzo prosty, skalowalny RESTful API dla MongoDB. Nie powinno być zbyt trudne zbudowanie komponentu React (Native), który odczytuje i zapisuje obiekty JSON w RESTHeart, który z kolei przekazuje je do / z MongoDB.
[Edytuj] Dodałem informacje o sposobie przechowywania danych. Czasami ważne jest, aby wiedzieć, ile pracy możesz wykonać podczas programowania i testowania, jeśli musisz poprawić i przetestować dane.
Edycje 2/2019 W ubiegłym roku (2018) eksperymentowałem z kilkoma z tych opcji, projektując projekt o wysokiej współbieżności. Niektóre z nich wspominają o twardych i miękkich limitach współbieżności w swojej dokumentacji (Firebase miał trudny do 10.000 połączeń, jak sądzę, podczas gdy Twilio był miękkim limitem, który można podnieść, zgodnie z dyskusjami z oboma zespołami w AltConf).
Jeśli projektujesz aplikację dla dziesiątek do setek tysięcy użytkowników, przygotuj się na odpowiednie skalowanie zaplecza danych.