I am about to undertake the development of a React Native app and am thoroughly convinced of the benefits of managing the app's state using Redux, however I'd like to make the app's data available whilst offline by using Realm for persistent storage. What I'm wondering is how Redux will play with Realm?
The app I'm developing will pull a large amount of JSON data via a RESTful API and then I'd like to persist this data to local storage - Realm seems to be an excellent option for this. What I'm unsure of however is how the Realm database will exist within the Redux store? Will it have to exist external to the store? Is using Realm within a Redux based app somehow a contradiction?
I've had a good search for articles describing the use of Realm, or other storage options (Asyncstorage or SQLite) for large datasets with Redux and could find little information.
The redux store is good when you have only react components dealing with the data. The store is a good way to maintain your application's state. For example, you do not need Realm to store the current login status or flags indicating whether the user has skipped login. The redux store wins the game here.
On the other hand, Realm is the best when you have to deal with complex queries or a large amount of data to be stored. The advantage of having Realm is that the data can be accessed within your react components as well as non-react components/classes easily. Realm gives you the advantage to monitor your data with the Realm Browser and build relationships between your models. Realm also wins the race if you have to do any offline sync.
Will it have to exist external to the store - Yes.
Is using Realm within a Redux based app somehow a contradiction - It depends upon what you are using the storage for.
Related
I am working with electron js and angular. And I want to use firestore database.
As far as I know, firestore is enabled with auto persistency.
First of all, will it work with my desktop application (node base / electron + angular)?
Second, let's say my application mostly works offline. And I need to do certain CRUD operations during these uncertain offline runtimes. So, if the first question's answer is yes, can I perform above operations in offline mode and will it sync as soon as the system goes online?
Third and last, if the answer to the second question is yes, then what if my system shutdowns that is desktop?
I will be glad for a detailed explanation of answers and a detailed explanation of how persistence works and is provided.
I am new to this channel. Please don't mind if I ask my question informally.
Firebase saves all offline actions to essentially an internal transaction pool for offline persistence. When Firebase does connect back online, it will attempt to sync all previous changes including transactions, document updates, and deletes.
The issue is the local pool wasn't made for extended offline use and over time, depending on how much data, it can slow the app down to handle all the data.
I've heard it should behave fine if the device is offline for about a month or two for general use but it might be better to support your offline app with an offline-first database such as PouchDB or NeDB and sync changes with Firebase as needed.
Say I have data fetching code like this
firestore().collection("USERS").get(userId1)
And say my app uses this user in multiple places. Normally with a rest API I would build some sort of data persistence layer, where I map id => users and let my app reuses the in memory data.
In the case of firebase though is it efficient to just call
firestore().collection("USERS").get(userId1)
Whenever I need that user model and just let the firebase sdk figure out if networking needs to happen.
I have an app that displays a list of items. Here is what I am doing.
When the app first loads I am making an HTTP request to get the list from the firebase database.
once the list is received the list is stored locally on localStorage for future use.
On future app loads, the list is loaded from localStorage to prevent unnecessary http calls
I am doing the above programmatically, i.e, saving data to localStorage and check for new data and getting it etc.
Does firebase provide any other way to the same?
There is no built-in support for cross page-reload persistence in the JavaScript SDK for the Firebase Realtime Database. Somebody is working on such functionality in the open-source repository, but no release was made with it yet.
If you need this functionality, I highly recommend looking into using Cloud Firestore. In addition to many other benefits, it supports cross page-reload persistence.
I'm working on a mobile app with React Native and Expo, providing security solutions. Project owner wants to store in app sensitive authorization keys, used to communicate with REST server and access secure data. He demands that these keys are at least encrypted, and hard to read from the outside, as much as possible.
I know about these topics:
Save sensitive data in React Native
Is React Native's Async Storage secure?
and about KeyChain, but they don't cover encryption and expo issues.
So what is the best and most common solution for making this data as safe as possible in React Native Expo app?
Expo now has SecureStore, which stores encrypted data.
Details: https://docs.expo.io/versions/latest/sdk/securestore
I am recently involved in a React Native project with security concerns like yours. Security is not an easy issue and I am not an expert, but this is what we did.
We used react-native-aes-encryption for encryption and hashing, react-native-rsa for generating public/private key pairs. In order to use these libraries properly, you better need to know basic cryptography concepts.
We used react-native-keychain to read/write data from keychain. Keychain is the way to go if you want to store some small sensitive data. It has been used in all Apple OS's in order to keep your passwords safe. That said this component is not working as seamless as expected on the Android side if you want to build your app for both platforms.
Other than that I have no idea about expo. I hope these libraries work for you as well.
I'm new with Firebase technology and I would like to optimize Firebase database size (including for decrease cost).
What are the different ways to decrease Firebase database size?
Can I simply use node names as short as possible, for example instead of having a node "user", rename this node "u"? (relevant if this node is very present)
Do there are other tips?
Here's the approach we take from one of our mobile apps:
We have a mobile app, web service, Firebase Database and Firebase Storage. We sometimes have a small SQL database as well.
We have the mobile app display data from Firebase but write data to Firebase via the web service, never directly.
We started with using Firebase Database as our storage, then changed to a hybrid Firebase Database + Firebase Storage mix.
We now store the "view data" is Firebase Storage and only store a "stub/pointer" in the Firebase Database (it reduces data size and it reduces traffic).
We end doing an extra read from Firebase Storage every time the value of a "stub/pointer" changes in Firebase Database, but that works for our scenario. We also don't do it for every situation, so we peek and chose where it makes sense to use this approach.
We ended up reducing cost - that was our main reason to search for a solution and it looks like that's your motivation as well.
Other than that, using short names for the key names may help as well.