I am planning to use a BaaS for a project, and am almost convinced to use Firebase.
The only thing I am wondering about it is what is it using as database?
I know that it is a noSQL database, storing element in JSON, a question on quora mentionned that Firebase once used MongoDB as it s database, but not anymore.
So my question is simply: What is Firebase is using under the hood to store it's data?
I was just poking around on the interwebz and found this, before read your question:
https://groups.google.com/forum/#!topic/firebase-talk/Doi4MP_A81k
The backend is proprietary. Since our data structure (a JSON-based tree) is pretty unique, it's pretty custom.
Hope it helps!
Related
I am wondering why aggregation (like SUM) is not built into Firestore when other NoSQL databases like MongoDB has them. Is it inherent to the design of firebase? Do you think it can be added soon?
This is a good question, actually.
Firestore was built for some certain use cases, that are not the use cases MongoDB is built for. MongoDB can be used for a lot of use cases, even those covered by Firestore.
Basically, the main idea behind the dev team was that they wanted to build a document database, easy to use, managed and lightweight. This led to making it without features like shardings, or aggregations, and so on, but still, the dev team knew some of them would be useful.
So they decided to leverage the possibilities offered by a cloud platform, and built it to support everything the platform (Firebase) could offer: Firebase Functions.
So, in the end, the answer is:
no, Firestore will never support aggregation functions. Or at least, that's not in the plans, as for now;
it is still possible to obtain a SUM, using a Firebase Function that will trigger everytime you perform a write operation, so you can update the SUM value. You'll need to store the value somewhere else in your firestore database, but that's a pretty good solution, and it is even documented here as an example. Only thing you have to remind is: the sum value will be "eventually consistent". It means that there could be instants when the persisted value is different from the real value, because the trigger is yet to fire, or because the function that will update the value has yet to finish, but this is the way Google designed Firestore and Firebase, so it's a good practice and pattern we can use.
There is also a third option when it comes to aggregations queries in Firestore (other than counters and client side aggregations)
You could alos also mirror your database to some OLAP capable database and do your aggregations there. Either build the sync mechanism yourself by listening to your data or use dedicated services.
Currently there are two Firebase Extensions you can install that do exacly that for you. "Firestore Big Query Stream" and "Firea.io". Both automatically mirror your data to another database and then allow for queries over that database.
This will allow you to use much more powerfull query languages (SQL / MQL) over your data.
(full disclosure I am one of the founders of Firea.io)
I've never used Firebase (or Firestore) before and I'm considering using it for my new mobile application. And I'm wondering if using Firebase only, without any additional server is a good idea. Firestore does a lot of things I guess, like authentication, security and scalability. So I really hesitate putting an another server into Architecture. But I have a plan to do many server-side stuffs like searching for text or calculating something.
I think the answer is "it depends", but I want to hear some advices from people who have used Firebase before about this topic. Thank you in advance!
Is it a good idea to use an additional server with Google Firebase?
Firebase will help you build apps fast, without managing infrastructure. So you'll be able to focus on your app development and not on how to maintain servers. Perhaps, if you have requirments that Firebase cannot handle, which I doubt it, you can use an additional server.
I've never used Google Firebase (or Firestore) before and I'm considering using it for my new mobile application.
If you have never used the Firebase suite, I recommend you get started by reading the official documentation. Before starting to use Cloud Firestore, I recommend first get more familiar with NoSQL databases.
And I'm wondering if using Firebase only, without any additional server is a good idea.
There are many apps out there that are not using any other server than Firebase.
Firestore does a lot of things I guess, like authentication, security and scalability.
Firestore is a scalable NoSQL cloud database that allow you to store and sync data for client- and server-side development. It does not authenticate users. For that, there is another product named Firebase Authentication that I encourage you to use it.
But I have a plan to do many server-side stuffs like searching for text or calculating something.
Here you can find more details about Firestore search options. Regarding calculations, you can do pretty much everything you can do in a regular SQL database.
I am considering firebase for an app - mainly for the real-time but other features like the analytics and authentication (and price) are other bonuses.
I have my own database and I want everything saved in there. Firebase will have a small portion of the dataset I push as it's needed.
So I'm basically thinking that the firebase data will be read only to the users. If a user comments, that will actually go to my server, I'll authenticate, clean, whatever.. and push to the that feed.
Are there problems with this approach? Are there other (better) ways to solve the problem?
This is a completely valid approach. Firebase is designed so you can use specific features that suit your needs.
I was wondering if it was possible and also, if someone can give his testimony of using both. Actually, for me, the real time thing is not that important, I care more about the NoSQL Database. I really care about pricing and I can see that Firebase prices are okay for almost everything (authentication is even free), but database is very expensive in my opinion (5$/giga stored and 1$/Giga downloaded ...). That's why I want to use DynamoDB for the database because it's way cheaper.
What do you think?
Finally, Firebase just released a new NoSQL service that is somehow similar to DynamoDB. No need to connect to DynamoDB anymore!
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.