Firebase’s Three Biggest Flaws

I love Firebase. You love Firebase. It’s great… except for when it isn’t.

I’ve been developing on Firebase for over a year now which is just long enough to understand it’s strengths and weaknesses. While it has many strengths, I’ve come to realise that it has three big flaws that will make your development timelines stop dead in their tracks when you reach them.

Firebase is probably the most developer friendly serverless backend on the market right now when you compare it to the competition; AWS has become increasingly bloated and enterprise-y, and Azure has always been primarily enterprise focused. However, if you’re a small team or a sole developer, Firebase is the service that has the goods for you.

That said, Firebase seems to have some missing features that just feel like gaping holes that I wish their development team would just fix. Worse still is that I only came across these missing features after I was already well invested in my technology choice.

If you are evaluating Firebase for a future technology project I am highlighting these issues here so you can go into your Firebase journey with your eyes wide open.

1. No automated backup or restore for Firestore

So, this is something I just completely assumed would be implemented. After all, Firestore’s closest competitor is AWS DynamoDB and automated backup and restore is an out of the box feature. Firebase Realtime Database also has this feature out of the box, but somehow they just forgot about it with Firestore? This seems like a no brainer, but sadly this doesn’t seem to be something the Firebase team even wants to address. Instead, they have a documentation page detailing a very convoluted set of steps for exporting and importing data from Firestore.

Not at all what I’d expect from a market leading cloud provider.

2. Authentication email templates can’t be customised

Firebase provides a feature rich authentication framework. It provides social authentication with many major providers, as well as the usual email and password authentication, and even passwordless sign in with email links.

The problem is you can’t customise the text of the emails it sends out for email address verification, email address changes, or passwordless sign in emails. A very unhelpful pop up on the templates that do exist tells us that “To help prevent spam, the message can’t be edited on this email template.”

There also isn’t any out of the box solution for sending a custom welcome email or a goodbye email for when people delete their account.

This seems like a small thing but it’s very frustrating because it clearly worked once upon a time and they disabled it because someone misused it for spam. For developers seeking to build a professional looking service on top of Firebase, this feels like a missing piece.

Firebase’s sort-of documented work around for this is for you to implement cloud functions to generate email action links and your own authentication logic where you can send your emails through your own SMTP server. Then instead of using their authentication API in your client, you will need to call your cloud function instead.

You then need to implement your own email action handlers, which is kind of like re-implementing Firebase’s authentication logic. And if you want any of this to work on a mobile app you’ll also need to set up Dynamic Links.

This all sounds like a giant pain in the ass for what should be core features of the Firebase platform.

If anyone at the Firebase team reads this, please work a bit harder on fixing this. I know spam is a big problem but there are other ways to prevent this without hobbling you service. Some suggestions:

• put a reasonable price on sending authentication emails. Say 10,000 a month for free and then 10 cents for every 1,000. You know, like AWS does… This should deter the spammers.
• or allow customisation of email templates as long as we configure a custom SMTP server.
• or have a review step for email template customisations that will filter out anything spammy. You could even use machine learning to work it out just like Gmail does. You’re Google, you can do it!

Anyway, this is so painful I’m probably going to have to write a lengthy blog post on how to achieve this very obvious functionality in Firebase’s broken authentication service because so far the best info out there is a very unhelpful short answer on StackOverflow from a developer on the Firebase team.

3. No full-text search functionality

Now this boggles the mind. Somehow Google, the company that completely revolutionised search, doesn’t provide an out of the box full-text search functionality on database records as part of their cloud offering.

Are you kidding me???

Instead, Firebase specifically recommends a third-party service such as Algolia or ElasticSearch to index your Firestore data in order to provide full-text search functionality. However, this requires implementing additional code to populate your Algolia or ElasticSearch index via cloud functions that execute on Firestore triggers.

It’s likely that you’ll only want to implement full text search on a subset of your total dataset, but there are issues with duplicating your data into another service just to make it searchable. The obvious ones are:

• the cost of using two database services
• the additional development time for integrating them
• and the fact that you then need to implement your authorization logic on this new database all over again.

This is so unbearably frustrating it almost makes me want to setup a MySQL database just so I can experience the nostalgia of the simple things like:

SELECT * FROM my_table WHERE text LIKE ‘%my_simple_search_term%’;

This all raises a very philosophical question for me which is “Sure, Firestore will scale better than MySQL but will I ever get a chance to scale if I’m screwing around with third-party integrations for full-text search?”

Perhaps the only solution I’ve come across that actually keeps this functionality within Firebase is Firesearch which despite the name isn’t actually part of the Firebase suite. Instead, it’s a third-party tool that deploys cloud functions to your Firebase project for the cost of a yearly licensing fee (starting at $50). It however still requires you to develop additional integration code to populate you search indices. Hey Google, why don’t you buy these guys out?

Honestly this should be a native feature. I don’t understand how it isn’t.

Conclusion

Dear Google, please fix your stuff. Firebase has some big flaws, but they don’t seem like they should be that hard to fix for a multi-trillion-dollar company. If you fix these you’ll have a perfect backend service.

Firebase is a very nice service otherwise. Please make it better.