Why is Firebase so popular among developers?

I personally like working with Firebase, especially because

  1. It provides great support for handling real-time data, especially when your application largely depends on the events on database.
  2. It provides methods for user sign up and authentication.
  3. Since the database is unstructured, database management is super easy and convenient.
  4. Integration with Google Cloud Functions - makes development fun.
  5. Testing your application, when it relies on client-side data is easy, you can easily add nodes without needing to go extra miles and running various queries for adding/removing data and analyze the changes

I personally like working with Firebase, especially because

  1. It provides great support for handling real-time data, especially when your application largely depends on the events on database.
  2. It provides methods for user sign up and authentication.
  3. Since the database is unstructured, database management is super easy and convenient.
  4. Integration with Google Cloud Functions - makes development fun.
  5. Testing your application, when it relies on client-side data is easy, you can easily add nodes without needing to go extra miles and running various queries for adding/removing data and analyze the changes to database.

Although it offers great features, it has it’s own cons especially no support for search or filtering data queries

Not to forget, documentation is well-organized and detailed.

PS: Amit Ashwini's answer to What are some good uses for Firebase? answer greatly for your question.

I work on Firebase Hosting, so you may want to take this with a grain of salt.

If you’re trying to write a mobile or we application that does anything interesting, at some point you’ll face a whole bunch of common problems. How do I know that this user is who they say they are? How do I send notifications to the user? How do I keep users from seeing each others’ data? What’s going to happen when I’ve got thousands of users, or hundreds of thousands? How can I host content and push it out to these users quickly wherever they are?

All of these are hard problems, and they require a lot of engineeri

I work on Firebase Hosting, so you may want to take this with a grain of salt.

If you’re trying to write a mobile or we application that does anything interesting, at some point you’ll face a whole bunch of common problems. How do I know that this user is who they say they are? How do I send notifications to the user? How do I keep users from seeing each others’ data? What’s going to happen when I’ve got thousands of users, or hundreds of thousands? How can I host content and push it out to these users quickly wherever they are?

All of these are hard problems, and they require a lot of engineering time even to come up with narrow solutions that aren’t very good.

Firebase provides an integrated platform that solves all of these problems (and many more) pretty well. Actually that’s false modesty: it solves these problems really well for most use cases.

I’m loving Firebase. Deployments are simple, free to host (on the Spark plan), and Firestore (the DB) is easy to use. Also GA is already integrated and has mobile test deployments.

I can now spin up MVPs in record time.

However, it isn’t perfect. Firestore is a bit limited and has some strange way of doing things because it is meant to be real-time…so great for chat apps. For example, you can’t do a “not” query.

Also, the costs can get out of control and surprise you in a very bad way. Google offers limited alerts and the current usage is there, but hard to associated with the costs with your act

I’m loving Firebase. Deployments are simple, free to host (on the Spark plan), and Firestore (the DB) is easy to use. Also GA is already integrated and has mobile test deployments.

I can now spin up MVPs in record time.

However, it isn’t perfect. Firestore is a bit limited and has some strange way of doing things because it is meant to be real-time…so great for chat apps. For example, you can’t do a “not” query.

Also, the costs can get out of control and surprise you in a very bad way. Google offers limited alerts and the current usage is there, but hard to associated with the costs with your actual usage.

Check out Firemon - control your Firebase costs for that.

First of all it is free..!

From development point of view, the database is unstructured and we don't need to write a single query to manage database. All the basic methods are available e.g. if we want authentication sign up, method signupWithUserAndPassword() is available.

And apart from database, we can host a website, crash reports are available and much more.

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the da

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the data in your Firestore database, not Google, so ignore the other answers about that also. If Google, and not the customer, owned that data, Firebase would have virtually no users. And, also contrary to the other answers, you can export data from Firestore. If customers weren’t allowed to export their data, who would ever use it?

Fourth, the suggestion to use SQL technology on your own physical servers (ones that you physically own) is not something that I think belongs in an answer to this question. SQL vs NoSQL and cloud vs in-house are decisions that you should have already made if you’re asking about a specific serverless provider. Clearly (at least apparently), you’ve decided on serverless NoSQL, which is definitely the most popular choice today. And between the two most popular providers, AWS and Firebase, they are designed to handle virtually any workload you throw at it. The most highly-trafficked applications in the world run on NoSQL serverless, like the Amazon marketplace, for example (AWS, obviously). If AWS can handle it, Firebase can handle it too. Google would never design its NoSQL serverless to max out at a certain number of users or level of traffic; it’s designed to scale virtually infinitely.

The only caveat to Firestore (and NoSQL serverless in general, really) is dollar cost—right now in 2019, anyway. Firestore was considerably more expensive only a year ago than it is today, think about that. I think NoSQL serverless will undoubtedly continue to become cheaper, including Firestore. But, right now, with a relatively large userbase, NoSQL serverless, like Firestore, can get expensive. But so can doing it all in-house. An in-house solution still comes with bandwidth cost, in addition to hardware and human cost. Hiring qualified backend engineers to build and maintain an in-house setup is not cheap (hundreds of thousands of dollars a year). Firestore (and DynamoDB) have excellent price calculators to help you predict your costs and you may be surprised to see how cheap it is with a modestly-sized userbase, even with 100k users.

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

Firebase is a group of services offered by Google (that used to be independant). Most notably, it offers what it calls a real time database.

This service allows you to store data in a format similar to JSON. Changes made to that data can then be shared among many clients in real time, without any special server side code.

Lets say you were building a grocery list application which is meant to be shared between several members of a family. So Bill notices that they are out of milk and adds it to the list. The developer just sends JSON representing that list to the real time database. The database

Firebase is a group of services offered by Google (that used to be independant). Most notably, it offers what it calls a real time database.

This service allows you to store data in a format similar to JSON. Changes made to that data can then be shared among many clients in real time, without any special server side code.

Lets say you were building a grocery list application which is meant to be shared between several members of a family. So Bill notices that they are out of milk and adds it to the list. The developer just sends JSON representing that list to the real time database. The database then forwards it to all other clients using that data and in real time Paul’s list is updated with the new item. Paul stops at the store and buys milk then checks it off. Once again, the developer simply sends the change to the data model, and firebase sends the changes off to Bill, who now knows he doesn’t need milk.

The aim is to let you build real-time data based apps without having to right much backend code (possibly none). Of course, this kind of model has its limitations. Firebase doesn’t really let you run any sort of logic on your data server side. Also, their database model is quite denormalized and not setup for complex queries.

They also offer some other services, like static hosting, authentication and file storage. But those are less unique.

Personally, I have found Firebase to be a great service for quickly building apps at Hackathons. I also use its static hosting frequently. But I haven’t built anything larger using its real time database.

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You can then run this bootstrapped backend on your own AWS instances, scale it up and down to keep costs low. There was any a price cliff like other BaaS services have where you end up paying thousands of you end up succeeding.

Then in the future as you grow, any back-end dev that knows Node.js can come in and continue scaling your platform, and the accompanying dashboard, and client sdks to do whatever you want.

So which is better? Depends on what you wanna do. If you want a legitimate company eventually around your product, Parse is EVEN better now that they are shutting down, because they are being so generous with their technology. Not to mention the community that is cropping up around these open projects to ensure that quality is maintained as time passes.

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perf

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perfect solution? It’s supported by google. It’s super super easy to use. It’s well documented. Any more questions?

You can build whatever app (prototype) with Firebase in no time. It might not scale, but this is not what’s it about. You just want to master front-end stuff, don’t you? Right.

Eventually your MVP might get traction. What are you going to do? Well, if it’s going to get “a lot” of traction, you can pay someone to build a scalable backend for you. If not, scalability will never be an issue. You just don’t have to care about it!

Build whatever you like. Focus on the things you love to do. Firebase let’s you do exactly this. Keep it going, cheers.

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser,

Hi,

I would like to answer this by sharing a real life experience. We created an IoT platform in my company named 700 Dollar Startups. It allows users to control home appliances using their smartphone. The platform also collects temperature and air parameters at your home.

We settled to use the following stack:

  • Firebase - for backend
  • Angular JS - FrontEnd
  • NodeJS - to run IoT code in raspberry
  • Ionic - for the mobile app

Below is our platform architecture.

Here are the advantages based on our experience:

  1. Three way binding - Firebase API solves the problem of raise condition in database. A client browser, back-office, and mobile consumer can update a data simultaneously without the problem of synchronization. As soon as data is updated, added, inserted, or deleted all update are automatically pushed to the client via API.
  2. Speed of Development - Google Firebase Database is NoSQL database with out of the box API connectors and wrappers for query purposes. As a result, rather than building REST API just like the traditional way of connecting thin client to database, with Firebase, a company can simply use their SDK to do the same purpose. As a result, business would be able to cut their development time by removing the API development component. Less scope, means less development cost as well.
  3. Realtime update - The old ways of doing things is that a client connected to database need batch update to get new sets of data. It is an inefficient architecture, imagine a program has to read 1 million records every fifteen (15) minutes with or without update. With Google Firebase Database, a client can be automatically triggered for refresh via Callback as soon as an update is made in the database. With thus technology, developers are assured to only get a new sets of data as needed basis. Here is the actual demo of realtime database update (See video below). As soon as data is changed in database, the LED’s state connected to Raspberry devices instantaneously changes status.
  4. Free- Developers and business owners can create two projects in Firebase for free. This means organization need not to buy premium license during R&D stage. It gives developers and decision makers enough time to learn and evaluate the technology.
  5. Authentication - It comes with a builtin authentication module. Supports gmail, Facebook, Twitter, and basic username and password login support. Integrating this module in your app is easy through their SDK.
  6. Rich API Document - The Firebase SDK is well documented and has lots of example over the web. On our case, we were able to try the SDK for NodeJS. Other Platform supported are IOS, Android, Java, and JS.

As for the Disadvantage

  1. No Data Explorer - This issue is more for developers. The Firebase Database does not provide an online tool to allow developers search for a data inside a node. It has a manual tree like data explorer but becomes complicated or difficult to traverse as dataset goes bigger.
  2. No built-in Authorization - One of Firebase strong point is it’s authentication module. However; it could had been better if it is shipped with a pre-created framework for authorization. To date, developers has to secure data and forms by manually coding the roles for a specific users.

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for co

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for complex stuff is simply not a viable option.

If you’re making something cool that just needs a fast, reliable database, user authentication and usage tracking, then Firebase is a great way to go. If you’re building something that has complex back-end business rules then you’re going to run into difficulties.

You can totally combine it with a custom application of course, store your data in Firebase and have a middleware layer that does the business logic, but for most business cases this isn’t really a good compromise.

Firebase isn’t a database. Firebase is an app hosting engine. Firebase applications are able to use Cloud Firestore. Firestore will scale performance up as you need it, but you need to be very aware of the pricing constraints. You really should look into the details yourself, but the tl,dr is:

  • Fairly cheap storage ($0.18/GiB/mo)
  • Not cheap writes/reads ($0.18/100K for writes, less for reads and deletes). It’s not a deal-breaker, but you have to be very aware of your query structure to avoid racking up excess queries.

The query patterns are going to be far more important here than your absolute dat

Firebase isn’t a database. Firebase is an app hosting engine. Firebase applications are able to use Cloud Firestore. Firestore will scale performance up as you need it, but you need to be very aware of the pricing constraints. You really should look into the details yourself, but the tl,dr is:

  • Fairly cheap storage ($0.18/GiB/mo)
  • Not cheap writes/reads ($0.18/100K for writes, less for reads and deletes). It’s not a deal-breaker, but you have to be very aware of your query structure to avoid racking up excess queries.

The query patterns are going to be far more important here than your absolute database size (100GB with 100 queries a day is going to be pretty cheap, but 10GB with 10,000,000 queries/day isn’t).