Beekeeper
Using MongooseIM to deliver highly efficient and scalable messaging performance.
The Company
The Challenge
Some of the basic requirements of a good collaboration messaging tool are:
1. Short-time delivery: Messages that don’t feel like instant, real-time communication don’t provide a good user-experience and can be a blocker to adoption.
2. Full archiving: Like any important workplace communication tool, there will be some messages that are important to revisit.
3. Smooth mobile experience: Where one or multiple devices can go offline, come back online and sync with the server and each other seamlessly.
All of these features are covered in MongooseIM, but there were other challenges specific to Beekeeper that needed to be solved.
One of the main challenges is providing an out-of-the-box solution for multiple companies, often with different needs and business units or working groups, with strict security requirements.
Two different customers might have similar or altogether different needs, but one thing they both require is complete isolation from each other- a space of their own to use.
Beekeeper needed to support an arbitrary and constantly changing number of such customers, all while keeping them isolated: the problem of multi-tenancy.
Of course, duplicating the installations is an inefficient solution which increases the demands on resources, increases the potential for error and increases cost.
Ultimately, what was needed was a partitioned installation with virtualised environments that showed different customers the right isolated version, based on the criteria of the business – aka XMPP dynamic domains. This way, each customer would live under their own XMPP domain that can be added and removed dynamically, at will.
The Solution
Erlang Solutions is a company that specialises in scalable and fault tolerant solutions to digital problems. One of its offerings, MongooseIM, is a messaging platform battle-tested over the years to be just that, a scalable and fault tolerant messaging platform. MongooseIM was chosen as the solution to Beekeeper’s problem, and for that, we prepared a plan of action, where the first point would be to ensure backwards compatibility with the offering Beekeeper already had. Devices needed to learn to speak the new XMPP protocol that supported chat, and likewise, any functionality the old system offered but wasn’t currently offered by MongooseIM needed to be implemented. While we supported the Beekeeper developers with XMPP training, documentation, and assistance, they supported us in implementing the features we were missing.
MongooseIM has a modular architecture. It consists of multiple blocks, such as inbox, group chats, and message archive management (MAM) which can be plugged in or disabled, depending on the project’s needs, and based on the served domain, i.e., one domain can serve MAM and another one might not. The overall idea is that it enables flexible solutions, where blocks can be added to the architecture with ease. Within this framework, we managed to create fine-grained read receipts, conversation metadata, integration with their message broker, and an extensive REST admin endpoint.
Once backwards compatibility was ensured, we added mentions, rich-text formatting, message metadata, simple read markers and the ability to mute or archive conversations.
Then there was the challenge of multi-tenancy. XMPP servers are usually exposed through DNS domains. Therefore it is common to map a single domain, or a very small set of them, to a node on the internet. MongooseIM was originally implemented to support one configuration set per domain and for these domains to be static. We needed to change a lot of the core code of our server in order to map a single configuration set to an uncountable and dynamic set of domains. This way, exposed features would not be looked up based on the domain, but on the configuration type for that domain, ensuring the internal MIM state is kept to a minimum and capable of serving an arbitrary number of domains, dynamically.