Pros & Cons of Local Persistence Strategies for React-Native Apps
Some of the benefits of using local storage or “fake backend” in React Native
Some of the benefits of using local storage or “fake backend” can include — improving the user experience, quicker loading times, simplifying the messaging-interface and the server-side functionality. Bellow are the Pros & Cons for 3 different data persistence strategies — with considerations for best practices and stage of product development (MVP to large-scale).
- AsyncStorage — a built-in React-Native Local and Session Storage
It stores key-value pairs of string-only data, not encrypted, limited to 5MB per app and asynchronous.
- Alleviates some of the need to rely on Server and External DB
- Readily-available and simple one-liner implementation
- Does not delay the loading of the app and can be quicker than data-fetching
- MVP Considerations — Possibly a simple solution for MVP/POC product — that could serve until switching to production-ready solution.
- silently reaches 5MB limit… — need to understand if 5MB is plenty for the needs of the app ?
- the limit of 5MB, as of IOS 8 — can be wiped clean in the case of low memory on device 😞
- Requires data type conversion as it holds only strings data.
- for further safety reasons: requires serialisation/deserialisation and content-security-policies in place to maintain safety of data.
Best Practice recommendation
- Widely used but not highly recommended for storing sensitive data. Not recommended for relying on persistence of data — as for the cons above.
Read more about it — Persisting Data in React Native.
2. REDUX-PERSIST or REDUX-OFFLINE — persist reducers, actions and state
Libraries that work with existing Redux implementation for global state management.
- Can work well in app which relies on Redux heavily
- Can hold light-weight data (such as series of IDs) that would be used to fetch data on server.
- Not the greatest for large size data storage
- The libraries are undergoing large amounts of changes and deprecated versions…
- Adds complexity with edge-cases for storing reducers, actions and state.
- ‘Chokes’ in android…
- Often strongly advised against — for the lack of pros over simple local storage implementations and the need to learn management (such as redux-loggers interface) for niche/slice of function it provides.
Best practice recommendation:
- Should be used only in well understood use cases — as simple JS object and local storage is sufficient most times.
Read more about it — Dan Abramov discusses ‘Why use Redux?’ specifically, instead of other simple solutions with an array of tutorials.
3. OFFLINE FIRST MOBILE APP — with local DB
offline-first mobile app development — assumes the user is offline, network is slow, server is not reliable, connection is with high latency, public wifi is proxied. Then the architecture consists of three key parts:
- Use of simple on-device database ( such as Realm fro React Native)
- Communication with server
- Server where the synced data will live so that it can be distributed to whoever has permission.
- seamless app performance on and off-line
- respect of user’s battery and network resources
- introduces an array of new app development patterns such ass pub-sub streams, caching and synching — additional layers where traditional CRUD app with a touch of localStorage would serve well.
- It’s hard 😅 — why most app developers run a mile from offline-first development
Read more about it — https://www.simform.com/react-native-database-selection-guide/
- None of the strategies stand out as the clear winner 😟 — as each have some draw-back — or at least something to watch out for.
- The AsyncStorage reads as the most straight-forward solution, suiting the apps that are guarantied to use less than 5MB, carefully handling sensitive user data with added encryption and security policies. Though with caution for memory-wipes 🤯
- Offline-first local database implementation seems to suit a well understood product with huge case for seamless offline performance. And a very keen technical team with plenty of resource — as the promise of performance is great — yet the potential run-ins to problems numerous as well…
- Libraries for local persistence that are undergoing huge changes and that integrate with Redux — fall into the grey land — with no strong advice to use those without a good use case — “Just store JS object instead!” 😅
Please, if you have come across any other elegant local persistence strategies, please share ! 🙌