So I have been coding a realtime chat app with flutter and firebase. Apparently there is a simultaneous concurrent connection limit of 200k on the RTDB, if my app reaches these limits, firebase suggests that I shard my database.
The problem with that is, that I cannot completely separate data from one database instance to another, as it's a realtime social media app, and one user should be able to access other user's information such as name, bio etc.
What I want to know is that, should I stick with firebase for this, or should I go with some other database.
You can always access data from multiple shards on your app as long as you know which shard does the required data belong to. You can also use Firestore along with Realtime database to suit your needs. Checkout the following answer for an example:
How to shard data Realtime Database for chat app?
This stores all user profiles and basic information about the chats (including which shard is the conversation stored in) which makes it easier to query list of chats of a particular user(s) from Firestore and then read messages from realtime DB.
Related
In my app, I have an SQLite/Room database. I want to introduce synchronisation between the devices of my users.
I want to combine my local SQLite/Room DB with a cloud Firebase DB.
I want my SQLite database to be stored in the Firebase Database when the users are logged in, otherwise let it store offline. Any changes to the local database should be reflected in Firebase Database when logged in. Also if a user deletes the local database he/she can retrieve it from Firebase Database. I just want to use Firebase for the synchronization between the local database and Firebase Database.
How can I do it? My app is in Android with Java as a backend.
In my app I have SQLite/Room database. I want to introduce sync between the devices of my users. I want to combine my local SQLite/Room DB with cloud Firebase DB.
I don't see any reason why you would add an additional local database to your application, since both Firestore and the Realtime Database have their own offline persistence mechanism. However, you can implement such a feature but you should take into consideration that the entire mechanism of synchronization should be managed by you.
I want my SQLite database to be stored on the Firebase Database when the users are logged in otherwise let it store offline.
This can be simply done without a local database. How can you achieve that? Simply by attaching an auth state listener to track the user auth state. This means that when you're using Firestore, you can specify the source for reading the data. For example, if the user is authenticated you can read the data from Source.SERVER, otherwise from Source.CACHE.
Also if the user deletes the local database he/she can retrieve it from Firebase Database.
There's currently no API that does that. You should implement your own mechanism. You should track the user when it deletes the database and then take some actions accordingly.
I made two databases in my project.
db1 contains a collection of unique tokens for each device that's currently wishing to receive notifications in my application.
db2 contains entities which will often update.
I've setup cloud functions to detect update triggers for db2 then send a message to a single device.
In my cloud function I'm reading and stashing in a collection all the unique tokens from db1.
How can I extend the cloud function to send the message to the collection of unique tokens from db1?
Should I use topics or groups for this? I don't know how big my audience can get.
I've looked at the firebase docs but can't quite figure out which to use.
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.
I had already saved all data like users or rooms contents on Firebase Database. Now I want to move all posts to Cloud Firestore for better queries.
But,
Can I take conditions from Realtime Database?
I mean all users data are in realtime database. So I want to get some informations from there, then decide whether it's accessible or not.
The security rule systems are different between Realtime Database and Firestore. There is currently no easy to way to simply copy from one to the other, or to make one recognize the other. If you're porting your data to Firestore, you'll have to write new rules by hand that functionally match the ones you were using in Realtime Database.
No, this isn't functionality that exists. You'll need to have migrated the data that the rules depend upon to Cloud Firestore first.
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.