Our path to a full serverless backend.

“curved concrete road beside grass” by Jannes Glas on Unsplash

9 months ago at Metropolis:lab we were playing with Firebase Realtime database for a small feature in our first (experimental) product @aboutit. Browsing through the Firebase host of features we realised that they (Google) were offering two interesting Beta products, one was Firestore, a natural evolution of the Realtime database and the other, a more interesting for us (humble backends) Cloud functions. Those two products caught our attention, since they were promising to remove the dire necessity of managing scalability and infrastructure of our systems and a really nice integration with our data store. Of course there was a catch in all of this, it was that we needed to sign a blood pact with the Firebase database and google products, which so far worked fine for us.

So out of curiosity, we started to develop an initial simple proof of concept of how to use those two technologies for developing and maintain all our business logic.

First we created a simple endpoint that was accepting some JSON object (we called trip) on `/trip`:

Creating an API to store our objects was fast and easy, so we got excited and we went forward to see if we could set up some kind of listeners that were reacting to changes in the data of our endpoint.

We thought about creating an update watcher, in fact it was actually quite fast and easy:

Well that was quite a work, so if our trip had it’s seats value changed to 0 we were deleting it from the OPEN collection (Firestore keyword for index).

Could it react to that deletion? The answer was yes, obviously:

So yes, this was quite handing and it worked nice for most of the basic use cases we had in mind for our future mobility product.

So we decided to jump into it an develop all our backend based in Firestore and Cloud Functions.

Of course this is were all started. Few months later this simple example has grow into thousands of lines of code and we introduced way more complex listeners.

Also, we had to add some not so clean tricks to overcome the limitations we have found in Firestore, but that is enough food for another post …

Thanks!