Build Serverless applications using Firebase and Google Cloud services

Yet another blog about software architecture.

Serverless?

Wikipedia: Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources.

Serverless give us the flexibility to scale applications without knowing it's internals. In this architecture we will use the following services: Firebase/ Firestore Real-time Database, push notifications service, Cloud Functions ( Functions as a service to deploy tiny microservices/ backend APIs), MongoDB / Elastic Search, Google Cloud Run, Task Queue, App Engine.

Firebase

Firebase offers various serverless and managed services like Firebase Hosting, RTDB, Firestore, Authentication, Storage, App Analytics, and other services like push notifications, etc. Firebase's entire workflow is built on top event-driven principles where you can monitor the database document changes in your subscriber ( that is changes can be subscribed in your frontend code, cloud functions, or any other backend services). Cloud functions (Node.js / Python ) is used as an application server and delivering dynamic content. Before we start talking about the advantages of this architecture we can discuss the cons first,

Most apps allow users to search app content. For example, you may want to search for posts containing a certain word or notes you've written about a specific topic. Even Cloud Firestore doesn't support native indexing or search for text fields in documents. Additionally, downloading an entire collection to search for fields client-side isn't practical. There is no offset inside firebase as well, so we can't do pagination inside the firebase. We can consider the following options as the databases/search engines,

1. MongoDB Atlas inside google cloud

MongoDB supports text search, filter search, geo-spatial queries, and facets by default. “MongoDB when properly indexed will yield query results in less than 0.010 seconds on a dataset of 1 million records.”

2. Algolia or Elasticsearch

To enable full-text search of your Cloud Firebase data, use a third-party search service like Algolia or elastic search. Even MongoDB after large volumes of the document starts to slow down after a million records. But search engines are optimized to yield more performance benefits in terms of search functionalities.

3. Google cloud Managed databases

There are multiple options that are there inside google cloud for data storage for eg: BigQuery and Managed RDMS databases MySQL and Postgres. Most of them are more expensive in cost and when you consider the RDBMS database you need to structure that as well.

In this example for the search-related operation, I have chosen MongoDB which is my favorite. Still, if you build an application that is more search-oriented I will recommend using elastic and there are relations everywhere ( for eg: Building a CRM) you may need an RDMS database. Databases choices are always hard to make and of course when your applications scale you will definitely end up building architecture which will end up with all these flavors together. From my experience, even MongoDB after 1 million documents start to slow down your search performance. Also Firebase offers geo-fire search for Real-time geo coordinates solution but recommend using Geo-hash algorithm instead.

When a document update/insert/delete event happens trigger a cloud function and update the same document inside the other datastores.

Stateful vs Stateless services

Serverless = stateless

If you want to deploy your applications as a stateful service then use a compute engine or Kubernetes engine for deployment.

NOTE: If you run any other services outside the serverless world like MongoDB inside computing engine connect both serverless VPC with Google Cloud VPC with serverless VPC connector it will improve network latency.

We have 3 main serverless deployment services inside google cloud App Engine, Cloud Functions, and Google Cloud Run.

Cloud Functions

Cloud Functions for Firebase lets you automatically run backend code in response to events triggered by Firebase features and HTTPS requests. Your code is stored in Google's cloud and runs in a managed environment. There's no need to manage and scale your own servers. It can manage following events / triggers,

• Cloud Firestore Triggers
• Realtime Database Triggers
• Firebase Authentication Triggers
• Google Analytics for Firebase Triggers
• Crashlytics Triggers
• Cloud Storage Triggers
• Cloud Pub/Sub Triggers
• HTTP Triggers

I recommend using Node.js as your programming language choice since debugging other languages like python is hard in my experience but firebase CLI gives you the flexibility to debug in your local machine itself.

App Engine, Cloud Run, Task Queue and other services

To deploy the backend code to serverless we have 2 other options than cloud function which is App Engine and Cloud Run. Cloud functions are meant to be tiny functions/services but here we can deploy monolith kind of workloads as well. Inside App Engine, the deployment is based on language choice like cloud function but in Cloud Run we can deploy any kind of stateless container service.

Read this: https://thatcoder.space/deploy-applications-using-google-cloud-run/

Use task queue for asynchronous tasks and other heavy lifting data engineering-related tasks. Make sure to run your subscribers inside stateful services or task queue has an architecture where you can call a functions/endpoint when a new data added to a particular topic. For sending push notifications to the web or mobile devices using cloud messaging and monitoring/logging can be done using analytics and stack driver tools.