This article is the third of a series around SST - Serverless Stack. I will try to let you discover some amazing aspects of this particular solution in the serverless world. You can find the first article here (introduction) and the second one here (some constructs presentation).

Firebase is a fantastic tool. It allows you to build mobile or web applications without having to manage a backend by yourself. But somehow, this comes with some drawbacks. In this article I will explain you why you may want to switch, and a practical guide to switch.

In a concrete example I will migrate a React application that is relying on both Firebase and a Serverless Framework backend to a single stack (with Serverless Stack)

Short Presentation of Each Solutions

• Firebase is a product backed by Google. It allow you to create mobile and web applications based on a set of Firebase components. It contains an authentication layer, a database (FireStore), a storage component to save files, and a hosting solution to ship your application. It’s also possible to rely on Cloud Function to run code in backend functions.
• Serverless Framework is a solution to host your backend components in a dedicated cloud provider without having to manage servers. For exemple on AWS it will allow your to manage Lambda functions easily.
• Serverless Stack is a new solution that can do what Serverless Framework offer. But it offer also to handle the hosting of your web application, and provide a better developer experience in my opinion. I have already written a couple of article on the subject: here for an introduction and here for some constructs presentation.
• React is a Javascript library to build user interface 😇

Why You May Want to Migrate?

I was running my system to manage Montreal library cards since a few year based on Firebase. Because I was using the free version of Firebase, I wasn’t able to use Cloud Functions. But to query Montreal library system, it was needed to run some functions somewhere. Back in the days, I have selected Serverless Framework to operate this backend API on my own AWS account. But it was not ideal, because I was dealing with too much stacks. Focusing on Firebase, here is a list of items that can limit you:

• Firebase is offering a limited set of functionalities: the integrated solutions is providing a really nice set of features for common web application (authentication, storage, database...). But it’s not easily extensible. When you use directly AWS, you can use any service provided by the cloud provider. Think about Machine Learning service, Queue systems, Container workload...
• Pricing model is not cheap: when you leave the no-cost plan (Spark), Firebase can be quite expensive, depending on your usage. For reference this classic article 30k bill on Firebase is a good reference! The backend-as-a-service model can lead to such issues if not well optimized. AWS is not cheap either, but you will pay only what you are using and you have more options to build your product (does the frontend is running query on the database directly or via a backend API?)
• Developer experience can be limited: local development is a must for serverless application : it reduces the feedback time it take you to test each feature. Firebase offer you a local emulator suite to provide you a local environment. It will allow you to test quickly the cloud function built, without waiting them to be shipped. But it’s only an emulation, not real cloud function running on your cloud provider. On the opposite, Serverless Stack is providing you a live lambda development environment that is relying on AWS services, not emulation.

Running the Migration in 6 Steps!

Step 1: Init your Serverless Stack application

Following the quick-start:

# Create a new SST app
npx create-serverless-stack@latest my-sst-app
cd my-sst-app

Take some time to explore the organisation of the folder. stacks/ contains your infrastructure setup, src/ will contains your Lambda function code.

Step 2: Migrate from Serverless Framework to the new application

In my specific case, I was migrating functions from Serverless Framework. The guys from SST have a decent documentation for this classic case: **Migrating From Serverless Framework.**