Adding serverless DB to your architecture

I started my journey with serverless databases due to a mobile project developed in Flutter: a relatively new technology developed by Google. While learning it, I discovered Firebase, the serverless suite from Google (Firebase) that integrates seamlessly with the Flutter framework

There are many interesting components in the Firebase suite: for instance a serverless Auth service that provides integrations with all the well-known providers like Google, Apple, Twitter, etc.

FireStore is a serverless document database, where you can define collections inside documents. It offers a minimal interface to insert some test documents and a part where you can define the access control rules for the database and the documents in the database.

Why should anyone want to migrate a database to a serverless database?

There are some advantages, mostly related to non-functional, if you ask me:

•  No maintenance tasks: you don't have access to any management console.
• Simplified security rules: a language for security rule definition is provided. You can enable fine-grained controls.
•  Planetary scale from scratch: I think this is the main selling point. You can start small and with a really small quote and scale without any upfront investment neither in your architecture nor in the infrastructure.
•  You pay for what you use. (this could be a double-edged sword).

The basic plan of Firebase is free and includes a considerable amount of requests both reads and writes.

The querying capabilities are very interesting, they provide operators and functions to filter data, although there is not a proper query language (as opposed to SQL for relational DBs or MQL for MongoDB).

I discovered later the main disappointment: it is not possible to run a wildcard search on the database. You can filter by intervals, but you can't search values inside a string. Was I reading right? It seem so. I just wanted to run a query to filter all names starting with Ba*.

Just to be clear: an SQL query like "Select from Composer where name like 'Ba'" can't be implemented directly.

To implement wildcard functionality, you have to add another component to your architecture.

Algolia is an indexing component that can be added to your architecture.

I described in my blog how to configure Algolia in a Firebase project.

How do you run a wildcard search in FireStore?

Well, you must add another component to your architecture. An indexing engine.

There are several in the market, but one of them is Algolia. Also, you need to create a trigger every time you create / delete a new document.

The indexing engine is a cloud service that works like a typical index, you define a few fields that are part of the index, and in this case, it's the responsibility of the programmer to update the index. Then, you can query that index, which returns your object ID, and then asks FireBase to return that object or the list of objects.

The trigger part must be implemented using a serverless function (and to use that capability from Firebase you need to enable a pay plan). There are some out-of-the-box functions to create this trigger as a serverless function.

The overall architecture of the solution running with this indexing system looks like the following:

The typical architecture is as follows.

1. A set of cloud functions monitor the FireStore database for changes in documents (Insert / Update / Delete).
2. If a change is detected, the index in Algolia must be created or updated.
3. To search in the app, the programmer has to query Algolia. It returns a list of object IDs.
4. The programmer has to query FireStore with the IDs provided by Algolia.

Again, we have to choose carefully the balance between the functionals, non-functionals and the need for a serverless solution. Depending on the size of your project it might be worthy to run an old-school traditional relational database, or a document-oriented database.