One of the hardest parts of any front-end application (native application or website alike) is the data layer. Where do I store information? That question alone can cause lots of headaches when dealing with large-scale applications. Well, worry not, as we'll be going over some of the different options you have at your disposal in your React Native applications today.
Often, while creating settings options, it can be useful to store a simple key/value pairings of serializable data (like JSON). In the web world, we'd use
localStorage. Ideally, we'd like a simple data storage for string-based data that has a
set, and a
clear method to handle data for us. Luckily for us, there is!
react-native-default-preference is an easy-to-add dependency that provides what we're looking for:
yarn add react-native-default-preference
Under-the-hood, it utilized native methods for storing data in a key-value manner. These APIs it employs is the
SharedPreferences API on Android and the
UserDefaults API on iOS. This native code utilization should mean that not only is the data straightforward to access, but speedy as well.
There may be an instance where you want to store a part of secure information to the device. For example, in my mobile Git client I'm currently writing, I'm grabbing an access token from the GitHub API. This type of sensitive data introduces a new set of problems when it comes to storage; conventional means of storing data are easily accessed from external sources, leading to a security vulnerability with such sensitive data. That said, both major mobile platforms have solved for this problem: iOS has its Keychain API while Android provides a KeyStore API. Both can be accessed using the
react-native-secure-key-store npm package :
yarn add react-native-secure-key-store
This package provides an easy-to-use key-value pattern, not entirely dissimilar to the one we used in the last section.
There may be times where having simple key-value storage isn't enough. Sometimes, you need the power and flexibility that a full-scale database provides. That said, not all of the data you need always requires a database to be hosted on the server. This instance is where having a local SQL database comes into play. React Native has a few different options for utilizing an on-device SQL database, but the most popular is using the
yarn add react-native-sqlite-storage
This package allows you to use full SQL syntax for querying and creating.
Want the power and utility of a SQL database, but don't want to play with any of the SQL syntaxes yourself? No problem, there is a myriad of options to build on top of SQLite using React Native. One of my favorites us TypeORM. Useful for both TypeScript and vanilla JS usage, it provides a bunch of functionality that maps relatively directly to SQL.
Alternatively, if you're looking for something with more of a framework feel, there's WatermelonDB. WatermelonDB is utilized with RxJS to provide an event-based fast-as-fusion alternative to more conventional ORMs.
While you're able to utilize something like Fetch or Axios to make calls to your remote API for data, you might want to utilize a serverless database to provide data to your apps. React Native's got you covered whether you want to use MongoDB Stitch, Firebase's Firestore or Realtime Database, or others.
While you're more than able to cache database calls manually, sometimes it's convenient to have your data synchronized with your backend. This convenience is one of the selling points of Realm. Realm is an unconventional database in that it's written natively and is not SQL based. You're able to integrate with React Native as a local database and connect to their Realm Sync platform to provide a simple to use synchronization between your database backend and mobile client.
A note about RealmDB: MongoDB acquired Realm in 2019. While this may seem like an unrelated note to leave here, I mention it because large-scale changes are in the immediate horizon for the platform. MongoDB is open about such. They plan on integrating the platform into a larger-scoped platform also (confusingly) called Realm. I mention this because if you're starting a new project, you may want to be aware of what these changes will have in store for your future. It seems like they have a lot of exciting things coming soon!
|Key-Value Pair Storage||
|Secure Key-Value Storage||
|SQLite without ORM||
|SQLite with ORM||
As with many things in engineering, where to store data is a broad-reaching and integral question to be asking yourself while developing. I've found myself mixing many of these options for a single application, depending on the context. Each has its strengths to draw from and weaknesses to consider.
If you liked this article and want to see more React Native content, consider subscribing to our newsletter below. We have more React Native content on its way soon. We also have a community Discord if you have questions or comments that you'd like to discuss with us!