Why we ditched the server half way and went for serverless? Do we regret about it?

In this article, I am sharing my own experience in my recent project. The rationale and use cases may vary.

Overview of The Project

We were building a web-based customer service live chat system. It includes conversation translation and social media platform integration. The chat feature is one of the cores of the system. The front-end is powered by Vue.js and the back-end is now powered by the Firebase ecosystem.

From Client/Server …

During the course of design, XMPP, a messaging protocol, was the first protocol we were looking into. For anyone who had ever dealt with XMPP, you should understand the pain of handling XML. Regardless, we tried Openfire as our chat server but soon we figure out a few points that deterred us from using it:

• Some XMPP standards are missing
• Resources required to customize it were enormous
• Limited documentations

Then, we looked into Ejabberd, a XMPP-compliant chat server, which is also the engine behind Whatsapp. They proposed a standard to handle multi-user chat known as MUC/Sub. Despite not being part of the XMPP standard, it indeed solves some implementation complexities for certain use cases.

Ejabberd is built with scalability in mind. However, it is built with a slightly not so popular language, Erlang. To make Ejabberd usable for our use cases, we had to build some Ejabberd modules. However, we faced the same problem — insufficient resources, especially one who knows Erlang well.

… To Serverless with Firebase

While we were still trying to develop the Ejabberd modules, we tried to look for alternative solution. And that’s how we encountered with Firebase and eventually landed on it. Firebase is a development platform which provides cloud services from authentication to hosting. A significant product that we heavily relied on is their Realtime Database and Firestore.

Both Realtime Database and Firestore are Database-as-a-service products that provides realtime synchronicity across clients. The significant distinction between both is the structure of the data stored, Realtime DB is a JSON store while Firestore is a document store, much like MongoDB but less powerful.

By using these two database, the sending of messages is no longer relayed through a centralized chat server as all messages stored are automatically synchronized across multiple clients.

What about other operations like registering a new user, creating a conversation, resolving a conversation? No, we don’t want all these operation to be written in the client apps. We wrote all these operations in serverless functions. To resolve a conversation? Yes, just call our function in the cloud. What about creating a new conversation? Yes, just call our cloud function.

Gains when switching to serverless with Firebase

We no longer have to:

• write modules in Erlang, but in Node (Firebase cloud functions uses Node)
• worry about lost of message in the relay route managed by the chat server.
• handle the scalability of the chat server ourselves
• and our codebase is now all Javascript (ES6)

What are the issues we have with Firebase?

Issues associated with Firebase cloud functions:

• Cold-start: an inevitable performance issue unless the functions are constantly called.
• Instability: Firebase cloud functions sometimes fail to start and execute properly.
• Dated Node.js runtime: The current Node.js version running in Cloud Functions is Node v6.14.0.

Issues associated with Firebase Firestore and Realtime Database:

• Limited query support: It is VERY limited, there is no ‘OR’, ‘NOT EQUAL’ or some other common database operators.
• Instability: especially in Firefox Private mode, the client library tends to fail with some internal error.

Did we regret about it?

We can’t deny that going for Firebase realtime databases saved us a lot of development complexities, however, it did introduce some inconvenience especially when querying the databases with their limited set of operators. Overall, with Firebase ecosystem, we saved a lot of effort and resources in developing the system.

Final Verdict

While Firebase ecosystem provides a lot of services which could potentially accelerate the pace of development, it is expected some more powerful features to be incorporated into their products and services to maximize their possible use cases. Do you recommend it? Let me know your opinions

First published on 2018-07-09

Republished on codeburst.io