To what extent is Firebase a production ready product to use as a serious company?

I dunno, do you think the New York Times, NPR, or the Economist[1]are serious companies?

I’m obviously biased. I don’t just work for Google, I work on Firebase. So take what I say with the customary grain of salt.

Using Firebase means that you don’t have to build your own notification, auth, storage, and static hosting infrastructure. It also means that you have to accept the limitations that Firebase’s No-SQL JSON-based database model places on what you can practically do. You don’t have to host the services yourself, but on the other hand you also can’t host the services yourself. It’s not free.

Footnotes

I dunno, do you think the New York Times, NPR, or the Economist[1]are serious companies?

I’m obviously biased. I don’t just work for Google, I work on Firebase. So take what I say with the customary grain of salt.

Using Firebase means that you don’t have to build your own notification, auth, storage, and static hosting infrastructure. It also means that you have to accept the limitations that Firebase’s No-SQL JSON-based database model places on what you can practically do. You don’t have to host the services yourself, but on the other hand you also can’t host the services yourself. It’s not free. Those are all trade-offs.

But they’re trade-offs that serious companies have been willing to accept.

Footnotes

Interestingly enough, I was in Las Vegas when Netflix was having a conference for a bunch if it’s employees there.

I struck up a conversation with a guy wearing a firebase shirt, and he said he was an iOS developer for Netflix. I asked why he had the firebase shirt on, and he said google gave it to them as part of the “swag” they got for using firebase in Netflix.

Now, if you search high and low, I couldn’t find any reference that Netflix uses firebase, but this iOS engineer confirmed it for me in person.

So to answer your question, if Netflix uses it in some capacity, I’m sure it can handle a de

Interestingly enough, I was in Las Vegas when Netflix was having a conference for a bunch if it’s employees there.

I struck up a conversation with a guy wearing a firebase shirt, and he said he was an iOS developer for Netflix. I asked why he had the firebase shirt on, and he said google gave it to them as part of the “swag” they got for using firebase in Netflix.

Now, if you search high and low, I couldn’t find any reference that Netflix uses firebase, but this iOS engineer confirmed it for me in person.

So to answer your question, if Netflix uses it in some capacity, I’m sure it can handle a decent sized app fine. The only issue is the JSON format is not very friendly to move over to a relational database when you DO want to switch.

A2A. Not sure why you’d have to ask this… when google acquired and integrated it, they already answered that for you.

I think it was ready even before that, though. It’s an interesting technology, but other technologies offer different features that might lead people to think of them as “more serious”. Some might argue that the style of data rules for security is inherently “not serious” and that better tools are needed for securing data and visualizing what’s protected and what isn’t, but it’s certaily possible to create a very real world serious use of firebase where it is amazingly ready and

A2A. Not sure why you’d have to ask this… when google acquired and integrated it, they already answered that for you.

I think it was ready even before that, though. It’s an interesting technology, but other technologies offer different features that might lead people to think of them as “more serious”. Some might argue that the style of data rules for security is inherently “not serious” and that better tools are needed for securing data and visualizing what’s protected and what isn’t, but it’s certaily possible to create a very real world serious use of firebase where it is amazingly ready and even the best tool for the job.

Firebase is completely production ready. In case you haven’t noticed yet, Google created, and actively works on Firebase. The APIs for Firebase are simple, I haven’t ever had a problem or a headache while working with Firebase.

Firebase also has extensive documentation on every one of its features, which are numerous, and include:

  1. OAuth
  2. Database
  3. Firestore
  4. Cloud messaging (deprecated in favour of Google Cloud Messaging)
  5. Push notifications
  6. User-based file storage

Firebase also has paid tiers, in which your application will also automatically scale, you can store more data, a bigger quota, etc. It is eas

Firebase is completely production ready. In case you haven’t noticed yet, Google created, and actively works on Firebase. The APIs for Firebase are simple, I haven’t ever had a problem or a headache while working with Firebase.

Firebase also has extensive documentation on every one of its features, which are numerous, and include:

  1. OAuth
  2. Database
  3. Firestore
  4. Cloud messaging (deprecated in favour of Google Cloud Messaging)
  5. Push notifications
  6. User-based file storage

Firebase also has paid tiers, in which your application will also automatically scale, you can store more data, a bigger quota, etc. It is easily a production grade library, and I highly recommend you use it. Support for many languages makes it an even bigger plus.

I would say it is pretty production ready. I use Firebase’s Spark Plan in one of my production apps and it works really well. I have never had any major issues and all of the bugs that I did have were caused by my coding and not by a bug in Firebase.

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.

Yes it’s an excellent choice.

  1. Performance: Excellent
  2. Learning curve: Minimal
  3. Cost: not bad (as long as you structure data and build your app right)

When you think about hosting cost though, consider how it might be offset. Were you to build your app with a more labor-demanding technology with cheaper hosting, you might need to keep some expensive developers on the payroll. With Firebase, a small team (or one person) can keep things under control. Hosting alone is a small part of the cost of owning a production website.

You need to ask yourself two serious questions before investing too much in Fire

Yes it’s an excellent choice.

  1. Performance: Excellent
  2. Learning curve: Minimal
  3. Cost: not bad (as long as you structure data and build your app right)

When you think about hosting cost though, consider how it might be offset. Were you to build your app with a more labor-demanding technology with cheaper hosting, you might need to keep some expensive developers on the payroll. With Firebase, a small team (or one person) can keep things under control. Hosting alone is a small part of the cost of owning a production website.

You need to ask yourself two serious questions before investing too much in Firebase though:

  1. Do I need to perform complex queries?
  2. Will I be heavily reliant on back-end code?

Firebase queries are pretty much like this: “Hey Firebase, give me the data at this node” and you get back raw data. You can maybe sort or limit, but probably not in any complicated way natively.

Firebase does not (yet anyway) provide a direct path to modifying the back end code. You can certainly write your own back end, especially if you use Node.js, and there are several ways to architect your app with it. To launch a chat app though, you don’t really need to worry about that.

You say it’s “in order to launch a startup” and you say you already know how to build a chat app using Firebase. In a sense there’s your answer right there. In general if you have an idea you want to implement and a clear path to move on it, take the path available to you. Even if you knew how to build it with other tech, I still might suggest Firebase due to the easy learning curve and the advantages of a real time database.

You’re open to learning new things. That’s great! You’d be a fool to be closed to new skills. When (if) your app scales to a point where the limitations of Firebase come into play it should be pretty easy/smooth to migrate away. Firebase is so light-weight and flexible that you could literally re-build your app full stack with other technology and then just plug it into your old Firebase as a quick-fix, then take your sweet time building out a new database and query structure.

There’s a pretty good chance you’ll never do that though. If your app really is limited to chatting, you’d be hard-pressed to run into a wall with Firebase. Some of the smaller limitations can be overcome by building a node.js “reactor” type server that just listens to Firebase for changes in data, then reacts in some way. You could also supplement Firebase with an API in that same or a different supplemental server.

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution see

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution seems to be to have a second project to use as a development/staging environment. Of course, if you want to have a few development environments plus a staging one before you roll out to production it starts to get messy. Being able to replicate your production environment using docker containers does make life and collaboration easier and you can’t do something like this with Firebase.

Nonetheless, I would not recommend just setting up your own backend and having to do software patches etc as some people imply is the alternative. The alternatives include using more scalable databases such as BigTable or ScyllaDB which can be used as a turnkey solution and then using things such as Cloud Functions, App Engine or Docker containers along with Kubernetes for your backend services. Just make sure that you encapsulate and abstract calls to your queues and databases so that you are not tied up in any one technology.

Of course, there are also very good reasons to use Firebase:

  • Authentication: Firebase takes care of your authentication allowing for different authentication methods that work on all devices. This makes life a lot easier.
  • On(change, add, delete etc.) Events: Realtime database is just amazing for frontend updates. You subscribe to data changes and the moment something changes in the database, your frontend updates instantly.
  • Cost: Especially in the beginning, it costs next to nothing to get started. As your app scales you start to feel the cost but in order to have a system that offers what Firebase offers you will be paying in any case so it is good to be able to start with very low fixed monthly costs and paying based on usage.
  • Speed of Development: Firebase allows you to launch your MVP in no time. It is not the best for large teams and complex projects but for MVPs it is just fantastic.

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.

ChitChak - Live Photo Sharing - Android Apps on Google Play

Check out our app here. This app is base on Firebase as backend entirely. From the experience of building this app, I can now quite confidently tell you that Firebase is not suitable to large scale project. An app like ChitChak that we build has hit some problem with limitation of Firebase. If I have to give one thing that bother me the most, it will be the problem when you wish to have some server side logic. Because you essentially do not have your own server side to begin with. So in order to do that, you can implement a server app

ChitChak - Live Photo Sharing - Android Apps on Google Play

Check out our app here. This app is base on Firebase as backend entirely. From the experience of building this app, I can now quite confidently tell you that Firebase is not suitable to large scale project. An app like ChitChak that we build has hit some problem with limitation of Firebase. If I have to give one thing that bother me the most, it will be the problem when you wish to have some server side logic. Because you essentially do not have your own server side to begin with. So in order to do that, you can implement a server app (we are using node.js) that listen to the change of the real-time database and respond to the change. Or you can provide a few API and have you app consume the API to achieve something you can’t with just purely Firebase. However, this seems like defeating the purpose of using Firebase as a backend service.

My suggestion for large scale and complex app is that you may consider using Firebase for user authentication or some sub-features of your app. Especially those that need real-time update (eg. chat, comment, likes, vote & etc.). The real-time database is really good at that and can save you tons of time of building your own Push service. You may also treat the real-time database as a Message Queue like services and implement the Pub/Sub or RPC system around it, but do not expect it work as efficient as a real MQ broker. Some other feature like Ad-word, analytic, and deep-linking are also useful and easier to enable by using Firebase provided libraries. Since they are now belong to Google which is the provider for some of this services, I think the support of all this services will only get better.

Lastly, if you are building a prototype for some prove of concept, it definitely help you to complete you prototype in shorter time. It’s super easy to use with SDK and it’s currently totally free within a reasonable quota.

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.