Mobile messengers have become very popular recently. At the moment, there are plenty of mobile messengers like Viber, WhatsApp, Skype, Telegram, each having its pros and cons.
In today's competitive market, an application must have a perfect design, be easily scalable, and be able to support heavy loads when necessary.
What's more, it must provide a high-security level so that users will be sure that their personal data are in safe hands. To ensure security, you can integrate end-to-end encryption which is already used by many famous messengers.
Building such functionality is a real challenge since it requires not only a lot of time for development and testing, and high developers' qualification, but also integration with reliable platforms for message delivery.
In our case, the best way was to use an open-source message broker RabbitMQ which supports different protocols of message delivery and has plenty of client libraries allowing to integrate it with popular mobile platforms (iOS, Android).
This solution let us pay more attention to architecture and business logic development and ensure stable work of message delivery and easy scaling.
RabbitMQ enables to easily implement the following features:
- group chats
- message delivery check
- receiving a message from the user while offline
- receiving a message on all client applications at the same time (iOS, Android)
- preventing unnecessary messages sending
- message delivery optimization in case of disconnection from RabbitMQ, e.g. during Internet cut-off
At the same time, the software engineering process always has some challenges. For instance, when making a mobile solution, our team had to implement communication of RabbitMQ with the server-side and communication with an Android app using the AMQP protocol.
In the beginning, we planned to use AMQP Objective-C wrapper for a librabbitmq-c library for iOS. But it turned out that it had many latent problems – this issue was solved by replacing AMQP protocol with MQTT. One should note that we didn’t have such difficulties with the client library on Android.
In addition, we had a challenge of correct message delivery configuration, which needed the right choice of Quality of service (QoS). As a consequence, we created a reliable system that supported heavy loads and their increase due to the expansion of the user base and user activity peaks.
The use of RabbitMQ in message application architecture helps easily solve a message delivery problem with the support of multi-user conversations and with several clients switched on.
Therefore, the RabbitMQ message broker is an effective solution for messenger development and implementation of many other IoT-based tasks. It completely solves the issue of communication with the application, which allows engineers to focus on implementing the app business logic.
Also, learn more about using the RabbitMQ for creating messengers and find out how to get started with RabbitMQ in its tutorial.
Latest comments (4)
I'm a DevOps engineer with a team that uses rabbitmq heavily in their legacy applications. While it's okay for small scale projects, it's not ideal for anything production or large scale. If the host crashes, you lose all the messages in the Q, if your architecture doesn't consider this and you can't redrive what you lost there's no way you can sustain.
Ideally such people should consider a managed queuing service like Sqs in AWS and others in other cloud providers.
The title of this post is really misleading.
Nice, very interesting.
Side topic, I really want to know how you feel about Kafka vs RabbitMQ in your use case.
Nice article Sergey. What would you say is the "leading by example" technology in the queue architecture?