![]() Instability: especially in Firefox Private mode, the client library tends to fail with some internal error.Limited query support: It is VERY limited, there is no ‘OR’, ‘NOT EQUAL’ or some other common database operators.Issues associated with Firebase Firestore and Realtime Database: Dated Node.js runtime: The current Node.js version running in Cloud Functions is Node v6.14.0.Instability: Firebase cloud functions sometimes fail to start and execute properly.Cold-start: an inevitable performance issue unless the functions are constantly called.Issues associated with Firebase cloud functions: What are the issues we have with Firebase? and our codebase is now all Javascript (ES6).handle the scalability of the chat server ourselves.worry about lost of message in the relay route managed by the chat server.write modules in Erlang, but in Node (Firebase cloud functions uses Node).Gains when switching to serverless with Firebase What about creating a new conversation? Yes, just call our cloud function. To resolve a conversation? Yes, just call our function in the cloud. We wrote all these operations in serverless functions. 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. 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.īy 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. Illustration of sending message without using a chat serverīoth Realtime Database and Firestore are Database-as-a-service products that provides realtime synchronicity across clients. A significant product that we heavily relied on is their Realtime Database and Firestore. Firebase is a development platform which provides cloud services from authentication to hosting. And that’s how we encountered with Firebase and eventually landed on it. While we were still trying to develop the Ejabberd modules, we tried to look for alternative solution. However, we faced the same problem - insufficient resources, especially one who knows Erlang well. To make Ejabberd usable for our use cases, we had to build some Ejabberd modules. However, it is built with a slightly not so popular language, Erlang. Despite not being part of the XMPP standard, it indeed solves some implementation complexities for certain use cases.Įjabberd is built with scalability in mind. They proposed a standard to handle multi-user chat known as MUC/Sub. Then, we looked into Ejabberd, a XMPP-compliant chat server, which is also the engine behind Whatsapp. Resources required to customize it were enormous.Regardless, we tried Openfire as our chat server but soon we figure out a few points that deterred us from using it: For anyone who had ever dealt with XMPP, you should understand the pain of handling XML. Illustration of the flow of message sendingĭuring the course of design, XMPP, a messaging protocol, was the first protocol we were looking into.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |