Not the person you responded to, but I just joined somewhere new and it's clear Firebase was the biggest mistake / is the biggest source of technical debt. It was helpful for bootstrapping 6 years ago, but now it stands out as the worst part of our tech stack. For our small shop, we will not be able to migrate any time soon.
- Most frustrating are the outages we have no control over. It seems like every other day, the server running our firebase instance mysteriously disappears from the internet. We can ping `my-app.fibaseio.com` but receive no events from it. This lasts anywhere from 5 to 25 minutes. Usually there is no blip in the firebase status page. The main devs have given up trying to debug it.
- We are nearing the resource limits of the paid plan for a single realtime database. We're working on splitting our one database into a master and sharding what we can.
- The particular eventual consistency and transaction semantics require workarounds everywhere. If you want an atomic transaction, you have to perform it on some common parent, but you are also encouraged to keep your data model flat and normalize as much as possible. Our integration test suite is tiny and horrendously slow because we cannot rely on Firebase to be timely, so there are huge timeouts everywhere that regularly take ages. Every past attempt at tuning the timeouts to be shorter eventually causes spurious failures a week later.
- Unless your data closely models the kind of chat application Firebase was built around, you end up needing a real database eventually. Not just to perform real queries with joins and complex logic, but also to essentially maintain indices that anemic mobile clients can use because the firebase filtered query semantics are limited to a single key. Now you need some kind of daemon to shuffle data in and out of your real database. Unfortunately, your real database is missing tons of foreign key constraints because that's the easiest way to handle firebase's eventual consistency.
That's just my take a month after joining somewhere intimately coupled to firebase.
It's a combination of a lack of developer bandwidth, fatigue, and typical difficult google customer service. Previously it was just a sole backend developer who also did the server operations/SRE type stuff plus a couple front end web developers. To them, it quickly became just a fact of life after repeatedly failing to find a solution. The customer service people don't like that, because these short down times always happen during standard business hours (only time our service is ever used). Complaints about disrupted sales pitches or customer demos go ignored.
I'm joining as the second backend developer, so maybe while I'm still green and have the naive bravery, I will go give it another shot next time it happens. I don't know much about advanced networking, but we suspect there's some kind of partition happening frequently between our servers and our production firebase instance. Uncertain how to debug that and how to work around it. It usually affects all of our servers, which are located in a single data center. I suppose next time I will try to track down and inspect the socket being used by the firebase SDK, but I don't really know what to be looking for at that point.
Mostly database-related issues as far as I understand. What I’m wondering is: is it related to Firebase only or more would it apply more generally to any NoSQL databases provider?
- Most frustrating are the outages we have no control over. It seems like every other day, the server running our firebase instance mysteriously disappears from the internet. We can ping `my-app.fibaseio.com` but receive no events from it. This lasts anywhere from 5 to 25 minutes. Usually there is no blip in the firebase status page. The main devs have given up trying to debug it.
- We are nearing the resource limits of the paid plan for a single realtime database. We're working on splitting our one database into a master and sharding what we can.
- The particular eventual consistency and transaction semantics require workarounds everywhere. If you want an atomic transaction, you have to perform it on some common parent, but you are also encouraged to keep your data model flat and normalize as much as possible. Our integration test suite is tiny and horrendously slow because we cannot rely on Firebase to be timely, so there are huge timeouts everywhere that regularly take ages. Every past attempt at tuning the timeouts to be shorter eventually causes spurious failures a week later.
- Unless your data closely models the kind of chat application Firebase was built around, you end up needing a real database eventually. Not just to perform real queries with joins and complex logic, but also to essentially maintain indices that anemic mobile clients can use because the firebase filtered query semantics are limited to a single key. Now you need some kind of daemon to shuffle data in and out of your real database. Unfortunately, your real database is missing tons of foreign key constraints because that's the easiest way to handle firebase's eventual consistency.
That's just my take a month after joining somewhere intimately coupled to firebase.