MongooseIM is a highly technical platform for businesses to build messaging and social apps, or add messaging and social features to an existing app. The fullstack MongooseIM platform offers various components, both for the backend (Erlang, Elixir) and the frontend (iOS, Android, Web) for you to pick up and assemble like pieces of a puzzle. Today, the MongooseIM platform delivers a new beta version of the messaging server, as well as new push notification server.
My name is Michał Piotrowski, and I’m MongooseIM platform tech lead. With this blog post I’d like to announce and describe our latest release. MongooseIM 2.1.0beta1 is one of the strongest releases I have ever worked on. It comes with new features on the XMPP level and it also contains much more internal, technical changes.
For this release we created a roadmap and gave the team the freedom to implement it. The end result is not only implementation of most of the items from the roadmap but also many corresponding changes resulting in improved code quality or performance.
For mobile devices
These days most of instant messaging applications are mobile first or mobile only. To deliver great product for mobile devices you have to be able to send push notifications to offline users in one way or another. This was possible so far with the mod_http_notification module. The problem with this approach is that you need to create your own HTTP service talking to
In this version we added support for push notifications as described in XEP-0357: Push Notifications . We also added a new service to our platform MongoosePush which can be used to communicate with both APNS and FCM. Configuration of all the required components to enable push notifications is no laughing matter. That’s why we create a detailed tutorial on this topic.
Thanks to this functionality you can enable push notifications in your application based on a standard way. There is no need to create ad-hoc, custom solutions.
For other services
In many cases you may want to get some of the events from MongooseIM in your other services. For example, to apply some business logic or implement a custom archive. Again, this was possible with MongooseIM so far by aforementioned mod_http_notification with the same limitations as described above.
MongooseIM 2.1.0beta1 comes with a new and more flexible way to integrate with other services in the whole infrastructure. Thanks to mod_aws_sns you can configure MongooseIM to push certain events to your Amazon SNS queues. The sky’s the limit in applying any business logic you may want on all the delivered events.
Full text search for MAM
Most modern instant messaging applications need full text search on the messages from archive. While not officially described in any XEP, it’s possible to add custom queries to MAM requests for instant full text search. This is exactly what we did in MongooseIM 2.1.0beta1. With this version you can use custom field full-text-search in your MAM query to get all messages matching provided pattern. Complete example can be found in the PR implementing this functionality. Be warned, this has its limitations:
- It works only with MySQL, PostgreSQL or Riak KV backends.
- MySQL and PostgreSQL implementation is not the most efficient as it’s based on SQL’s full text search.
Please take a look at mod_mam documentation to see how to enable this feature.
Continuous load testing
In developing the MongooseIM platform we are always focused on the quality of our product. That’s why we integrated MongooseIM with services like travis-ci , coveralls.io and gadget-ci a long time ago. Thanks to these improvements, every single change is properly tested. Code quality and test coverage are also monitored to ensure we deliver the best possible quality.
For the past few months we’ve been working on another service which helps us deliver better products.Tide is our own service integrated with MongooseIM build pipeline. Thanks to this service we are able to continuously load test our pull requests to see the performance impact of proposed changes.
The usual way of connecting to a XMPP server is based on a request response pattern. The client sends a stanza, waits for the reply from the server and then sends another stanza. This is required when the client connects to a server for the first time. Many things about the server capabilities are not known to the client so it needs to wait for the response to proceed. When communicating with familiar server, where the clients know about all the features provided by it, almost all initial requests can be combined in one request.
This improves connection or re-connection times significantly. Following diagrams shows re-connection time (with stream resumption) with and without pipelining.
As you can see the reconnection time with pipelining takes at most less than 50ms while without pipelining it’s at least 150ms .
This improvement doesn’t come for free though. These changes increase MongooseIM’s memory consumption. Tests on our Tide platform before and after the change was merged shows that MongooseIM consumes around 200Mb more memory on a load test with 50K users.
Erlang distribution over TLS
Many of our customers were asking if it’s possible to encrypt the communications between Erlang nodes in the cluster. They need this for various reasons, and improved security is always an important factor when deciding whether to encrypt Erlang traffic or not.
Our answer to this problem is yes, it’s possible. Magnus Henoch already described how to do this for Erlang in general in hisblog post. Starting from there we extended MongooseIM to simplify such encrypted setup and add it to 2.1.0beta1. Detailed documentation on how to encrypt Erlang traffic for your MongooseIM cluster you can read in the Distribution over TLS guide.
You can expect a dedicated blog post with load test results on this topic in the near future. Sign up to the Erlang Solutions Newsletter to be notified of this blog post when it’s published.
Please feel free to read the detailed changelog , where you can follow links and find the code changes.
Special thanks to our contributors!
From beta1 to final release through beta2
This release is a beta which means we are still adding a lot of changes before final release. We work to ensure that our product is as high a quality as possible with every change – I strongly recommend giving this beta a try. This also means that you can influence the final 2.1.0 release by giving us your feedback.
Peer to peer or mediated binary streaming
We will deliver an ICE/STUN/TURN server, coded in Elixir, to allow peer to peer and one to one media streaming, like voice, video, screen sharing, and whiteboarding. The signalling part, named Jingle , is already available.