Why Firebase is a great solution to build an MVP

One of the most popular Baas solutions, Firebase, was launched in 2011 and acquired by Google in 2014. 

Today this real-time database offers 18 services and holds one of the leading positions on the market.

We are continuing our series of articles about building MVPs of technical products, having already covered where to start and what are the possible limitations (or lack thereof).

# What is Firebase

Firebase developed by Google is one of the leading BaaS (Backend-as-a-Service) solutions on the market. It allows connecting and sharing of data between Android, iOS, and web applications. It is an infrastructure that doesn’t require setting up servers and can be configured with an online web console. With Firebase’s real-time database, all of your data is synced in real-time and can still be persisted and processed offline.

Based on our experience, we concluded that Firebase is especially suitable for building MVPs. We have broken down the advantages and the possible obstacles to prof this statement. Let’s look at the details. We are continuing our series of articles about building MVPs of technical products, having already covered where to start and what are the possible limitations (or lack thereof).

To dive deeper into building platforms and applications from scratch, we want to assist you with making decent choices of tools from an engineering perspective. No matter what your product is about, you will most likely need to store users’ data or share large files. Today we will evaluate Firebase as a possible backend solution for your project.

# Firebase advantages:

• As Google’s platform, it is widely recognizable and thus easier to pitch to clients. Given Google’s notoriety, customers happen to have immediate faith in it.
• Configuring Firebase is quick. It allows you to have a faster project start, and it also can be assembled approximately 2X faster than the Python backend.
• While working, you can keep an eye on your project in Firestore where you can synchronise and update data in real-time.
• It also comes with several built-in advantages, which will save working hours in the future: integrated Authentication (with easy, secure logins) and integrated hosting, HTTPS included, etc..
• It allows building scalable applications. Scaling a service in Firebase means multiplying the number of deployed function instances.
• It also offers performance monitoring to measure your app’s performance from the user’s point of view, which is extremely important when working on an MVP.
• With Firebase, there is no need to worry about infrastructure. You don’t have to set up servers, upgrade lower-level software, patch vulnerabilities, issue SSL certificates, set up proxies and databases, load balancers and watchdogs, etc.
• While Firebase might have its limitations, being Google’s product, it is permanently evolving. Today you can start testing Cloud Functions Locally since Firebase has recently introduced beta Simulator Suite, which looks very promising.
• You can extract any complex logic to the corresponding Google Cloud Instance.

Concluding above, at the very early stage of building your MVP, you probably are looking for a database that guarantees high speed, doesn’t take long to learn, allows an iterative process, and is affordable for a starting business. A lot of these things have already been taken care of for you by Google Cloud Platform. Thus, Firebase fits these criteria.

Now let’s take a look at the possible difficulties of maintaining Firebase.

# Firebase limitations:

• With Firebase, it is difficult to handle complex database joins and migrate large amounts of data. This should be taken into account if building a complex project.
• While scalable, at a certain point, it may become more expensive to build large applications.
• Cold start of functions. The way it works is when a Cloud Function hasn’t been called in a while, and the underlying instance may shut down automatically to minimize used resources. After shutdown, when Function is called for the first time, it could respond slowly (= cold start) while the underlying instance is starting up again.
• At the moment, Cloud Firestore doesn’t offer a migration/backup mechanism out-of-the-box.

There is also a threshold, after which using Firebase may bring issues and technical debt during the process, and we will extensively cover it in our upcoming articles.

# Firebase as a time-saving solution

Firebase is not the only tool on the market, and for a starting product, the choice process may be challenging. We did it for you and compared alternative options and their features regarding the development estimations on a real-life example.

Given: Firebase, Django/Flask, AWS Amplify — options for building web applications.

Task: to deploy and run a client-server web application called «Hello, world!».

Requirements: HTTPS, browser cache, database connection, access to deploy through ssh/console.app, data synchronization with backend, and a possibility to work offline.

There is no CMS or Admin panel side app to edit, change, or create the same data as a mobile application can.

Basically, you have one destination point and three possible means of transport to get there, which will differ in terms of time and efficiency. Here is what you can expect in terms of duration employing various toolsets.

1. Setting up the project:

   • With both Firebase and Django/Flask it will take around 3 to 4 hours, including project skeleton and deployment.
   • With AWS Amplify this number doubles to 8 hours, which will result in formation templates for each module and a deployment script.

2. Adding the authentication and authorization feature:

   • It will take absolutely no time in Firebase since the solution comes with the above feature right away.
   • It will take from 6 to 8 hours with Django/Flask to add the authorization feature with password reset/change flow.
   • AWS Amplify will allow you to wrap up the out-of-the-box authorization and password reset/change flow in 4 hours.

3. Data CRUD operations with updates in real-time:

   • It will take 2 hours to implement with Firebase using SDK or 4 hours if CRUD Cloud functions endpoints.
   • With Django/Flask it will take 4 hours.
   • It will take the same time with AWS Amplify with a few lines in GraphQL schema and a couple of resolvers, given that you use AWS Appsync.

4. Google Analytics:

   • Сomes out of the box when you use Firebase
   • For Django and AWS approach analytics is additional efforts (2-4 hours)

5. Push notifications for your users:

   • A messaging server is already included as SDK in Firebase.
   • With Django you need to set up a separate mechanism
   • AWS needs extra efforts.

6. Servers monitoring and load monitoring:

   • Also included in Firebase, the developer/client can check Graphs by yourself.
   • With Django, there is an additional time (a few hours) to set up 3rd party service for this purpose.
   • AWS Amplify has its own dashboards, no need for additional efforts.

Let’s summarize hours estimations in the table:

Time spent on setup Firebase vs Django and AWS

In total, using Firebase will help you win 22 hours compared to Django/Flask and 18 hours as opposed to AWS Amplify. When it comes to time efficiency, Firebase holds a firm position in between Django/Flask and AWS Amplify.