Firebase: The Good, the Bad and the Ugly.

Serverless Part II.

Photo by Cayetano Gil on Unsplash

After our first post about our initial steps into the serverless world provided by Google Firebase suite, as we promised; here is a new post about what we learned from such experience, the good things, the bad stuff we found and the so so or ugly stuff we had to manage to make it useful for our use case.

Just to put you people in context. We are currently developing a mobility solution, the main idea is to provide a service through mobile apps that will help people to share trips to work and from work. So for that, we need some real time feature, to store our documents, do searches, send notifications and an easy integration with the mobile clients.

We picked up Firebase as it was solving the part of being easy to integrate with mobile clients. And we choose GCloud functions, because well, we like to try new things here 😁. But also the promises of not having to worry about complex deployments, infrastructure management and scalability issues were too tempting to not pass by, specially being a small team, as we are, that just wanted to produce a minimum vaiable product as soon as possible.

Having said that, let’s take a look on what we discovered (so far) by developing our entire backend stack using GCloud functions and Firestore database.

The Good:

One of the best things we can say about using GCloud functions is how easy are to deploy, really it’s astonishing easy to set up an environment with the whole solution. I’m kind of sorry for the devops of the world. But I can simply deploy and set up my backend with a simple:

 firebase deploy --only functions

Google (and our credit card later 💸) will handle the rest.

Integration with mobile and the rest of GCP suite it is so easy that one would wonder how could people managed to build it before. Do I need to to send a push notification? No problem: this one liner will solve it for your:

messaging().sendToDevice(currentTokens, notificationPayload)

Just need to store the mobile tokens somewhere and define a notification payload, which is just a simple typed json that mobile sdks will understand. What about defining a Pub/Sub system, no problem Google got your back. Payments, easy with stripe, paypal, etc. You can take a look here on quite a good bunch of useful examples.

Real time; It is super easy to set up a websocket like environment through listeners and subscriptions, so you can develop chats, lobys, and triggers that react to changes to your data.

Fast to develop, it’s so fast to develop that feels like being in a constant rodeo while your produce features, bug fixes and improvements. Really, getting rid of infra makes this quite appealing, especially on the initial phases of a product.

The Bad:

Well, obviously not everything are bells and whistles within the Firebase suite. There are some things that are plain bad and could be a total product killers.

First and foremost I would say that the lack of flexibility on the Firestore database, could be for some the killing point. Specifically on the (lack of) capacity of doing queries to your data. For instance, one of the limitations that one might encounter is that your could not do range based queries over different variables; i.e filtering by x >= start AND x <= endtime. No geolocated queries, and no advanced functions on query time, in short, very basic database properties. Also, Firecloud is a schema-less Nosql database so forget about joins and the like and the typical drawbacks of Nosql play at full scale.

Functions cold start, or warmup of your endpoint. As any serverless solution in the market, one would suffer from this quite annoying and hard to avoid problem, the first call to your service will always take quite some time.

Long deployment times. It is easy to deploy, but it takes quite a lot of time so, if you are developing and want to test something quick it will take quite some time to deploy and sometimes it will fail.

Really hard to debug, so one of the prices you pay for letting others managing your infra and services is that you are oblivious to details, so if something is not working properly, you cannot jump into it and start looking on what’s going on. Although, Google provides with two different ways to check logs; with either Google cloud or Firebase, and an error reporting interface with Stackdriver Error Reporting. It is still a bit far from optimal; i.e. we see errors in the log files that are not being reported in stackdriver, there is a delay between both services and also we don’t have much control on how Stackdriver parses our logs.

Vendor locking, once you go serverless with Firebase, you go for the full pack of services with Google Cloud. It is true that they have a very good and complete suite, but for instance we have to use Stackdriver, which we have found is not mature enough.

The Ugly:

Something that we could live with but we wish we didn’t have to deal with.

Firecloud events are triggered more than once, and could not be triggered at all without any warning so, idempotency , consistency and linearity is something that one must take into account when programing listeners that react to those events.

Testing is a real pain, although recent initiatives like firebase-functions-test, have eased this burden, it takes a lot of time, in comparison to more traditional approaches, to produce quality tests.

Currently only node.js and typescript are supported languages, :(.

Easy to end with tones of spaghetti code due the previous points, be wary, being fast at developing shouldn’t be against losing quality(!!).

Everything bounded to an index.(ts/js) file, all the functions (or endpoints) you need should be declared here, but that’s the javascript way afaik.

The cost, is not easy to determine or even get a clear idea of how much your service or product will cost, it feels that if we screw up abusing the lookups into the database we could get bankrupt quite fast so, as many of that kind of services, having a plan about what is costly and what is not is hard to have.

But at the end the good things overcome the bad and ugly ones, and we went full in with GCloud Serverless proposal, we find out quite fitting for fast development of minimum viable product development, will be it work for a mature product? Well, time will tell but we hope to discover it soon.

Thanks for reading and see you space cowboy.