If you clicked this article because of the word “Firebase”, you have probably been a part of a mobile application development lifecycle at some point in your life. Some of the services offered by Firebase like Firebase Cloud Messaging (FCM), Firebase Dynamic Links, Firebase Remote Config have become synonymous with the features they implement in your applications. We at Applozic use FCM for push notifications for Android applications built on our platform. Firebase is currently among one of the top app development platforms relied upon by developers across the globe.
That said, Firebase’s offerings in the Backend-as-a-Service(BaaS) space are not the be all, end all in terms of application development. In this article, I would like to explore some of the shortcomings other application developers have encountered with Firebase, and why your application might be better suited with your own backend solution.
What is Firebase?
Firebase helps you develop high-quality apps, grow your user base, and earn more money. Each feature works independently, and they work even better together.https://firebase.google.com/use-cases
Firebase is a mobile application development platform from Google with powerful features for developing, handling, and enhancing highly functional and versatile web, Android, and iOS platform applications.
Firebase categorizes its services and by creating solutions of these three main problems for developers:
- Build : Accelerate and scale app development without managing infrastructure
- Release & Monitor : Release applications with confidence and monitor their performance and stability in realtime.
- Engage : Boost engagement with rich analytics, A/B testing, and messaging campaigns
Firebase’s ideal customer
Firebase Use Cases page has some interesting application use-cases which cover some of their more popular offerings and how these services solved a business problem or boosted the customer retention after onboarding. Of course, these are the high visibility success stories where businesses were profitable and Firebase helped them take the next step in their development journey. You can find their showcase use cases here.
To understand what type of customer would benefit the most from Firebase services, let’s take a look at their current pricing plan, and see how George (a fictional character) created an application using Firebase.
Building the basics for your app
George woke up from bed with a great idea for an app and wanted to implement the minimum viable product to make sure the idea gets implemented. Firebase offered George unique services with dedicated APIs that helped with the initial setup of creating a database, managing authentication, storage, messaging, testing, etc., without ever having to understand what is going on in the backend.
The phrase “pace over perfection” is best suited for use cases like this, where the priority is to get a feature implemented over worrying about the nitty-gritty of implementation and since George used only the Free plan, he was able to get an application shipped in minimum possible time.
Scaling up and whittling down
A month has passed since George released his app, and he is happy with its success. The app has over 10,000 downloads on mobile and people are using and re-using the app at a moderate level. Everything is great on the public side of the picture.
Behind the scenes though, the application is reaching its quotas on most of the services. George’s app has a lot of inbuilt messaging capabilities and users are sending rich messages (GIFs, emoticons, and animated features) and attaching files in one to one conversations and that is fulfilling his Cloud Storage quota rapidly.
George considers moving his storage solution to a more cost efficient service like AWS S3, but finds out that due to a Vendor lock-in, he cannot simply migrate from Google Cloud Storage without having to completely rebuild how the app functions.
As the number of users increase, George wants to implement phone authentication as a security measure but finds that the quota for Firebase authentication has already reached its limit, and he needs to either scale up to the paid plan or not implement this feature.
Seeing the increasing challenges in maintaining his app in a free to download version, George wants to implement a few exclusive features which then he can ship as a paid app for regular users. He wants to implement customized API calls that will utilize the Realtime Database to provide the users with accurate data. However, Firebase APIs are non-customizable and the quotas for the RTDBs are constraining the ability to onboard new users or implement new features.
Point of no return
The time has arrived for George to make a decision regarding the app’s future. To ensure his app keeps functioning, he has to take one of the following decisions:
- Move to the paid plan by sourcing investment and giving up partial/full control over his app.
- Move to the paid plan by monetizing his app and asking users to pay to use the service.
- Move away from Firebase services and create a robust backend and storage solution that can withstand scalability without causing disastrous financial repercussions.
Solution 1 and 2 might be good for the short term if the practicality of cost can be solved by George. However, unless George is able to scale up his development efforts and gain a lot more users for his app, these solutions are not going to help in the long term.
Solution 3, while being the most suitable for the long term, is not viable from the perspective of development or immediate implementation.
So who exactly is the ideal customer for Firebase?
- If you are just starting your app development journey, Firebase and its services are a great place to start implementing a minimum viable product.
- If you are an Enterprise with oodles of funding and already use the Google Cloud platform, Firebase complements your application with robust APIs and services.
- If you are somewhere in between, Firebase might not be the correct solution for you!
What developers say
Multiple articles on blogs and users across social media sites like Reddit, Twitter have opined their views on Firebase, and I have tried my best to summarize them here.
Costs increase exponentially based on data usage
As we saw in George’s case, Firebase’s current pricing plans are suitable for the initial development of an app (free plan using less data) or enterprise level customers (high cost high value). While Firebase does offer a free plan, but that comes with hard quotas and restrictions that might hinder your application’s usage.
Works only with NoSQL Databases
Firebase offers two database options – Firestore and Firebase Realtime Database. Both of these have a NoSQL structure, and there is no option to use a relational database.
This becomes a big problem when a developer wants to migrate some or all of their services to other providers and since Firebase uses JSON to store data, there is almost no easy way to be able to migrate from the existing database.
Firebase can be geo restricted
Firebase is a subdomain of Google, and their official website is https://firebase.google.com, the services can be blocked in any country by a domain ban. This means that if George wanted to publish his app in a country where Google cannot be accessed, he will have to rebuild his core infrastructure to something that is available in that country.
You can find the list of active disruptions to Google on this page.
Vendor Lock In
Developing an application using a non open source tool set can be frustrating when you want to add a certain feature or migrate to another service, but due to incompatibility, you are forced to stay with the same service, sometimes at a higher price or lower quality of service. This is called “Vendor Lock In”, and it is a prominent detriment in complex applications which use multiple services.
If you are in the beginning stages of your app development journey, and your app can be considered “small” – it doesn’t require complex data queries and relies on real-time updates, Firebase is one of the most robust and cost efficient BaaS that you can utilize.
However, as the complexity of your app grows and there is an acute need for customization, high volume data transfers, better data structuring for analysis and querying, Firebase loses its sheen. As a developer, it would be more efficient to create your own backend or build upon existing IaaS platforms.
We will be glad to know how you have used Firebase services and what prompted you to use/leave Firebase in search of a solution. If you have ever developed using Firebase, do share your experience as a comment below!