I know that I could implement a counter in my application but using an api would still be a cleaner solution - if one exists?
Basically, Firestore has Spark free tier limits (think 50,000 reads/day) that I don't want to exceed. So whenever my app was going to do firestore reads, I would like a way to simply ask firestore whether I'm over a certain number.
I'm also reading that Google intentionally got rid of Firebase spending limits.. which seems really sketchy... Impossible to set the Cloud Firebase daily spending limit
There is no such API as part of Firebase. The ways to monitor usage are documented here, but none of them is an API.
You might be able to get some data through the Cloud Monitoring API. But this API isn't made for client-side access though, so you'll have to wrap it yourself.
A final alternative would be to look at a service like https://firerun.io/ who automate a lot of this.
I would like to use Firebase Firestore for my next project but I need some help understanding the limitations of what is possible with Firestore queries.
Basically, I would like to perform queries over collections with large amounts of documents but upon doing research I have come across conflicting information.
This video (from the Firebase team): https://youtu.be/W3xIOQu0h1w?t=11m50s states that you can perform a query over a collection with "billions" of documents and maintain the same level of performance compared to a query over a collection with a few documents.
Then, I came across this github issue where the poster states that queries are taking too long and demand alot from the system. A member of the Firebase team answers by stating that performing a query over a collection containing 35k documents is beyond the "performance envelope".
So can someone point me in the right direction concerning Firestore queries and its limitations.
Please let me know if I was not clear in any part of this post.
That GitHub issue you linked to is specifically talking about offline searches. This means the Firestore backend service is not available, so the search is performed on the client. This is a very different situation than when the client is online and the service can perform the query in a massively scalable way. (Client apps are never massively scalable.)
Google just released Cloud Firestore, their new Document Database for apps.
I have been reading the documentation but I don't see a lot of differences between Firestore and Firebase DB.
The main point is that Firestore uses documents and collections which allow the easy use of querying compared to Firebase, which is a traditional noSQL database with a JSON base.
I would like to know a bit more about their differences, or usages, or whether Firestore just came to replace Firebase DB?
I wrote an entire blog post all about this very question, and I recommend you check it out (or the official documentation) for a more complete answer.
But if you want the quick(-ish) summary, here it is:
Better querying and more structured data -- While the Realtime Database is just a giant JSON tree, Cloud Firestore is a little more structured. All your data consists of documents (which are basically key-value stores) and collections (which are collections of documents). Documents will also frequently point to subcollections, which contain other documents, which themselves can contain other documents, and so on.
This structured data helps you out in two ways. First, all queries are shallow, meaning that you can request a document without grabbing all the data underneath. This means you can keep your data stored hierarchically in a way that makes more sense to you without having to worry about keeping your database shallow. Second, you have more powerful queries. For instance, you can now query across multiple fields without having to create those "combo" fields that combine (and denormalize) data from other parts of your database. In some cases, Cloud Firestore will just run those queries directly, and in other cases, it will automatically create and maintain indexes for you.
Designed to Scale -- Cloud Firestore will be able to scale better than the Realtime Database. It's important to note that your queries scale to the size of your result set, not your data set. So searching will remain fast no matter how large your data set might become.
Easier manual fetching of data -- Like the Realtime Database, you can set up listeners in Cloud Firestore to stream in changes in real-time. But if you don't want that kind of behavior, and just want a simple "fetch my data" call, Cloud Firestore has that as well, and it's built in as a primary use case. (They're much better than the once calls in Realtime Database-land)
Multi region support -- This basically means more reliability, as your data is shared across multiple data centers at once. But you still have strong consistency, meaning you can always make a query and be assured that you're getting the latest version of your data.
Different pricing model -- While the Realtime Database primarily charges based on storage or network bandwidth, Cloud Firestore primarily charges based on the number of operations you perform. Will this be better, or worse? It depends on your app.
For powering a news app, turn-based multiplayer game, or something like your own version of Stack Overflow, Cloud Firestore will probably look pretty favorable from a pricing standpoint. For something like a real-time group drawing app where you're sending across multiple updates a second to multiple people, it probably will be more expensive than the Realtime Database.
Why you still might want the to use the Realtime Database -- It comes down to a few reasons.
That whole "it'll probably be cheaper for apps that make lots of frequent updates" thing I mentioned previously,
It's been around for a long time and has been battle tested by thousands of apps,
It's got better latency and when you need something with reliably low latency for a real-timey feel, the Realtime Database might work better.
For most new apps, we recommend you check out Cloud Firestore. But if you have an app that's already on the Realtime Database, I don't really recommend switching just for the sake of switching, unless you have a compelling reason to do so.
Reasons to choose Cloud Firestore over Realtime Database
It is an improved version
Firebase database was enough for basic applications. But it was not powerful enough to handle complex requirements. That is why Cloud Firestore is introduced. Here are some major changes.
The basic file structure is improved.
Offline support for the web client.
Supports more advanced querying.
Write and transaction operations are atomic.
Reliability and performance improvements
Scaling will be automatic.
Will be more secure.
Pricing
In Cloud Firestore, rates have lowered even though it charges primarily on operations performed in your database along with bandwidth and storage. You can set a daily spending limit too. Here is the complete details about billing.
Future plans of Google
When they discovered the flaws with Real-time Database, they created another product rather than improving the old one. Even though there are no reliable details revealing their current standings on Real-time Database, it is the time to start thinking that it is likely to be abandoned.
Suggest link from google as well :
Firebase Real-time Database vs FireStore
Extracted from google docs, a small sumamry here:
FireBase Real Time DB is JSON based NO SQL DB, meant for mobile apps, regional, and used typically to store and sync data between users/devices in realtime / extremely low latency.
FireStore is JSON 'like' NOSQL DB meant for high concurrency, global, easily auto scaling persistence, designed for any clients (not only mobile apps) with typical use cases such as asset tracking, real time analytics, building retail product catalogs, social user profile, gaming leaderboards, chat based applications etc.
Cloud Firestore is Firebase's database for mobile app
development. It builds on the successes of the Realtime Database with
a new, more intuitive data model. Cloud Firestore also features
richer, faster queries and scales further than the Realtime Database.
Realtime Database is Firebase's original database. It's an efficient,
low-latency solution for mobile apps that require synced states
across clients in realtime.
To choose between Firebase Realtime database and Cloud firestore based on your application requirements, read official documentation here.
First, I read the documents on the Firebase. And it is still not neatly organized. I'm going to publish kind of an app for the first time.
That's why I get a lot of confusion.
I think this is a place for beginners to ask questions also.
It has only one photo on profile in my app.
I mean my app is text-centric, not photos.
I think the Realtime-Database would be advantageous because it requires less storage space.
But bandwidth is a problem. I do not know exactly what the bandwidth is. Bandwidth is said to occur when downloading, but when reading text into my database is it called bandwidth?
I do not have much money and I want to try it in an optimized environment. What do you think would be better?
My app doesn`t need photos other than profile pictures that can identify each user.
I am a beginner, so the contents of the documents are difficult and I am asking questions.
I don't want you to think it is a duplicate question.
In firebase realtime database bandwidth is calculated for data transferred from the database (and it is given a quota for the month). If you go through their docs you can get a nice idea. Here's the link to their pricing documentation.
To store your one image (as far as i know) you'll have to use "storage" in the firebase and save the reference in the firebase database.
Since your app is text based, you can most probably get away with their free tier, which is cool. Have fun, hope this helps you
here's the link to their database documentation.
I'm working on a IOT project, where we are evaluating to use firebase. We have a prototype implemented which works fine for real time data. Since the data is critical for client they want to be able to retrieve the data at later point of date. I couldn't find much about a persistent storage in the firebase website, any of you have idea on if we can use firebase alone or do we need to transfer it to you a cloud based store like google cloud store, if so what is the reliable time for which firebase will hold the data. Assuming you choose the right plan.
Thanks
Kamal
Firebase is a persistent database. While you certainly can setup a way to transfer the data to an archive, if you structure your data correctly, there shouldn't be any need to do so. You haven't really indicated what those requirements are, however, so it is difficult to thoroughly answer your question. (If you have one.)
There have been several demonstrations of using Firebase as part of an IoT infrastructure. Consider, for example this presentation by Jenny Tong (#mimming) about doing exactly this.