I'm building an app which uses Firestore for storing most data. The app has a chat functionality and I was considering using Realtime Database for that. What are the benefits of using Firebase Firestore vs Realtime Database for this chat functionality? If there is no difference, should I use Firestore for everything?
P.S. I have already read the firebase comparison of the two https://firebase.google.com/docs/database/rtdb-vs-firestore and I am still not sure which way to go about this.
FB RTDB was designed for a chat application but is not so great for more than simple querying. Firestore was developed to improve the querying requirements and is newer. Newer doesn't necessarily mean better, depends on the use case. Their pricing models are very different, so you need to understand how your use case will be charged.
You can use both of course. They can work well together but if a simple chat requirement is all you need, I would use RTDB.
PS. The unique keys generated in RTDB for each new record are automatically in chronological order, which relates back to it being designed for a chat app. There is a caveat though, the chat messages may still get out of order because the keys are generated on the device and if the device clocks are slightly out and messages are being exchanged rapidly then you may get a miss timing. The way round this is to write each record with a property of server time...and use that to sort the chat messages. Hope that helps your decision.
PPS. RTDB charges for data storage volumes and data download volumes. Firestore charges for storage and db reads and writes. There will be a lot of the latter in a chat app so I would recommend running some what-if scenarios in Excel.
Related
I have a small question about managing data between Firebase Authentication and Firestore.
For example:
The Firebase Authentication API stores the email of the user.
But we also use Firestore to store the other details about the user.
So the question is...
Should we also store the email on Firestore ?
I feel that a duplicate data is never a good idea. But having the email directly in Firestore should be faster and easy to access.
Thank you
I feel that a duplicate data is never a good idea.
When working with NoSQL solutions I'd highly recommend letting that feeling go. Read NoSQL data modeling and watch Getting to know Cloud Firestore for more on this.
One of the things you'll learn from that is that your data model will typically evolve for the use-cases your app needs. For example, if you want to allow the user to see or search all email addresses, that functionality is not standard available in the client-side Firebase Authentication SDK. This means you have a few options to build this functionality for your users:
The server-side Admin SDKs of Firebase Authentication do have the option to look up the email address for a user, or to list users. So you could wrap this functionality in an end-point you create and secure (for example with Cloud Functions).
You can also write the user information to Cloud Firestore (or the Realtime Database) when the users registers, and then look it up there from within the app, using Firebase's security rules to ensure all access to the data is authorized.
This is just one example, and as I hope is clear, it is based on speculating that your app needs certain functionality. But it's quite common that developers store user information that is also in Firebase Authentication in a database too.
I have built an app using firestore as we are interested in the realtime updates portion of things. However,we are not building a website that has CRM component where a lot of reports will be generated. The contents of that CRM are all new. There is only one report that would need firebase data as well as the new data (you can say 1 report out of 20).
I was thinking of building the CRM backend off mysql DB? Do you recommend to go with this approach or shall I do the CRM in the same firebase/firestore db?
Thanks
If you are looking for a real-time backend database for your CRM, then the Firebase RTDB / Cloud Firestore would be ideal for this. I'm not sure why you'd want to add a mySQL component, unless you are going to create some reports that require complex joins. However, if your data is modelled correctly, this also shouldn't be an issue.
Take a look at this video to get a better understanding: What is a NoSQL Database? How is Cloud Firestore structured? - Get to Know Cloud Firestore Ep.1
It seems odd to me that Firestore would charge me for read queries to locally cached data, but I can't find any clarification to the contrary in the Firestore Pricing document. If I force Firebase into offline mode and then perform reads on my locally cached data, am I still charged for each individual entity that I retrieve?
Second, offline users in my app write many small updates to a single entity. I want the changes to persist locally each time (in case they quit the app), but I only need eventually consistent saves to the cloud. When a user reconnects to the internet and Firestore flushes the local changes, will I be charged a single write request for the entity or one per update call that I made while offline?
Firestore could potentially fit my use case very well, but if offline reads and writes are charged at the same rate as online ones it would not be an affordable option.
As the offical documentation says,
Cloud Firestore supports offline data persistence. This feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline. You can write, read, listen to, and query the cached data. When the device comes back online, Cloud Firestore synchronizes any local changes made by your app to the data stored remotely in Cloud Firestore.
So, every client that is using a Firestore database and sets PersistenceEnabled to true, maintains it's own internal (local) version of the database. When data is inserted/updated, it is first written to this local version of the database. As a result, all writes to the database are added to a queue. This means that all the operations that where stored there will be commited on Firebase servers once you are back online. This also means that those operations will be seen as independent operations and not as a whole.
But remeber, don't use Firestore as an offline-only database. It is really designed as an online database that came work for short to intermediate periods of being disconnected. While offline it will keep queue of write operations. As this queue grows, local operations and app startup will slow down. Nothing major, but over time these may add up.
If Google Cloud Firestore priceing model does not fit your use case very well then use Firebase Realtime Database. As mentioned also in this post from the Firebase offical blog, one the reasons you still might want to use the Realtime Database is:
As we noted above, Cloud Firestore's pricing model means that applications that perform very large numbers of small reads and writes per second per client could be significantly more expensive than a similarly performing app in the Realtime Database.
So it's up to you which option you choose.
According to this If you want to work completely offline with Cloud Firestore you can disable network by :
FirebaseFirestore.getInstance().disableNetwork()
but firestore will cause client offline error for first user get request, that you must consider this error as empty response.
Firebase's documentation has the following paragraph:
Using Cloud Firestore and Realtime Database: You can use both databases within the same Firebase app or project. Both NoSQL databases can store the same types of data and the client libraries work in a similar manner. Keep in mind the differences outlined above if you decide to use both databases in your app.
I can't find any documentation on how to add a Cloud Firestore to an existing project with a Realtime Database, though. I will ultimately upgrade to Cloud Firestore, but would like some time to experiment and learn before I convert the production database.
Does anybody know how to use both databases in the same Firebase project?
When you go to your project in the console and choose the Database product, you should see something like this the first time:
This is a selector that lets you choose to see either Realtime Database or Firestore in your project. You can switch between the two with this selector.
The first time you select Cloud Firestore, it will ask you to configure things. Start in "test mode" to set things up for full read and write without authentication to get started quickly, but of course your should always have rules set up in production.
After you set up Firestore, you should be able to use both client SDKs to access both databases independently.
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.