Firebase Is Not Production-Ready; So Don’t Use It

I’m constantly drooling over new technology. That’s what we do as technologists. And when I hear about a new product, I’ll usually give it a shot. I heard about Firebase from a co-worker about a year and a half ago. He described it as a real-time database, which I had never heard of before. He said that instead of polling an API to request new data, you could instead connect straight to the database via a connection and have your web app update in real time. This sounded amazing. I haven’t worked on very many apps that required constant updating, but the idea alone was enough to convince me to try it.

Trying Firebase

After a weekend of putting together a Firebase and Angular 2 “hello world” app, I was sold. I had two Chrome windows up and as soon as I entered a message on one screen, the other screen showed it. And when I say, “as soon”, I mean something like 500ms. I started by building my next side project on Firebase. And then the next one after that, and the next one after that.

Around this time I was working on a new project at work. We were planning on building an Express API with an AngularJS front-end. The timeline we were given, however, didn’t match the robustness we were hoping to build. We had to cut some corners. Since Firebase allows us to bypass the API layer and go straight to the database from the front-end, the API was the first corner to cut.

We built the entire application on Firebase and AngularJS. To be clear, this application was soon to be the bread-and-butter of our startup. This was going to replace our entire previous PHP application – our money maker. After three months of hard work, it was time to launch. We were a bit behind schedule, so much of the final testing phase was expedited. We had hundreds of clients expecting a new application on Monday morning. This new application was going to solve all the problems they had with the old system. The problems they were threatening to cancel over. And we were filled with great hope that the 60 hour weeks were about to end, and Christmas was right around the corner.

The expensive mistake

The night before launch-day we hit a wall in our testing. Our application was working great with our test data, but as soon as I migrated all our client data from our current MySQL database to our new Firebase database, we had a sobering realization. We never fully stress-tested our application with lots of data in the database. We couldn’t even start our AngularJS application.

The networking tab in Chrome Dev Tools showed the Firebase calls taking upwards of 90 seconds each. This is because Firebase didn’t have a “where” clause, so we had to download every record in the collection just to get one. For example, if I want to ask, “are there any records that have X as a value for this property?”, I couldn’t do it. I would have to download all the records over HTTP, then in JavaScript filter the records to find the one or two that I was looking for. This issue wasn’t isolated to one component either, we had this issue in 5 or 6 places in the application, leading to a 90 second load time.

There were several other issues that were preventing us from going live. Most of which are already mentioned in this article by Crisp, so I won’t repeat them here. The main take away from this incident is that there was no way we were going to be ready on Monday morning – and in fact we weren’t. Most of our clients were patient and understanding, but we no doubt lost a sizable chunk of our clients.

Migrating away from Firebase

After several very long meetings, we concluded that there was no technical solution to making Firebase work. There was just no way. Without proper querying capability (like in MySQL or MongoDB), there was no way we could get the data we need without getting lots of data we don’t. So we had to fall back to more proven technologies: MySQL and Express.js (well actually LoopBack). It took us another 6 months to launch.

This was a very dark time in our company’s history, and the decision our team made resulted in a huge waste of time and money. We’ve grown as a team since then and fortunately we’re doing very well now. But we were damn close to closing up shop because we put too much faith in a new and unproven technology.

Recommended reading: Scaling a Node.js API With Google App Engine

  • SammySweatSocks

    What back end did your team move to after that?

    • We’re using MySQL for a database, and a Node.js RESTful API running on Google App Engine. We’re about to move that over to a Docker+Kubernetes cluster though.

  • Teeraroj P.

    Can new Firebase database “Firestore” fix that problem?