Over the last ten years, we have helped A LOT of companies add value to their products using MongooseIM or XMPP based chat applications. This has allowed us to partner with, and get insights from companies spanning almost every industry and company size. You may wonder how much variety and complexity a team who specialises in scalable Instant Messaging is exposed to, but the truth is, the only thing that ties these projects together is MongooseIM, our scalable, customisable XMPP server. Once we dive deeper into the needs of our clients, we usually find deployments need new features, tailored to their specific need, to help them achieve their most critical business objectives.
Customisation is what sets the work we do apart. We make sure that your Instant Messaging is fit for purpose. Even when XMPP or MongooseIM offer a rich enough chat experience, there are other details we mare are right to deliver a reliable solution. This includes taking into consideration your workload and usage scenarios to ensure that you have the scalability to guarantee uptime.
How can we create or improve a chat experience for your business and its customers?
Building and maintaining a chat application is a continuous process. We join our customers at many different stages, and depending on their needs, we can help in different ways. Let's take a closer look at some examples.
Building a bespoke solution.
We can become an embedded part of the team that builds the service. This allows us to architect and build the solution together from scratch. From the very first day, we learn about the unique properties of the customer and how instant messaging helps them to achieve their goals. As a result, we can use our expertise to make sure the system is built perfectly, from the start, before any less-than-ideal decisions are made. An added benefit of this for our customers is that their team gets to see how we go about architecting and designing a best-practice system. That way, there is a natural knowledge sharing of every step in the process, so when the product is launched and in-use, your team is familiar with how to operate and maintain your system. When possible, this is the perfect option for both the organisations we work with and us.
Improving and optimising before release.
We can't always be there from the start. Sometimes, there is a proof of concept application ready which needs improving, often because there is a technical issue that needs to be solved before the release.
At this stage, it's still possible to help design the architecture of the entire chat system. We can also deploy it to the production environment and make sure it can cope with the increasing load introduced by new users. There are a number of common problems we help solve for companies looking to optimise their chat before release.
One of the most common reasons companies need help at this stage is that developers who have less experience with XMPP have implemented inadequate solutions which have already been solved by the existing, public XEP - XMPP extension.
We also often see problems arising when a custom extension is built on top of an existing one, which, when done incorrectly, can cause significant complications.
In the lead up to the release of a chat solution companies often need help with custom integrations.
This is especially true for companies adding real time chat to an existing product. In many cases, this can be done outside of the MongooseIM code, on the other hand, it's usually more scalable and efficient if it can be run within MongooseIM. Not every company has the need to hire full-time Erlang developers, especially for implementing a few integrations. Our team are experienced, ready and happy to help with custom integrations to ensure the reliability and scalability of the release.
To ensure success when working with an existing product that has yet to be released, we often need to take a step back and look at the product, its goals and its failures holistically. From there we can suggest the best solution. This may mean we need to rethink the existing implementation and change or reshuffle some of the code. In extreme cases, we may need to throw away large chunks of the existing solution to ensure the release is successful. This is the last resort and a decision that is taken collaboratively in the name of reaching an optimal solution.
Increasing the scalability of your chat to allow you to handle more users.
Your instant messaging is deployed and running. Your product is growing successfully. It should be a time to celebrate, but often increased adoption or use of a chat application comes with increased scalability issues. These need to be sorted fast and future-proofed to avoid giving your users a poor experience and damaging the growth you've worked hard to achieve.
Our role is to find the bottlenecks and fix them. We study the architecture, the server setup, configuration, enabled extensions and customised code. Then, we decide on the best possible solution together, in collaboration with our clients.
Improving or customising your chat application.
All right, the app is deployed, and users are chatting, so far so good. How can joining forces with us make things even better? There are many reasons companies will come to us to improve an existing instant messaging solution.
Many of our customers come to us to develop unique functionalities that are necessary for their success. We help by designing the extension on the protocol level and implementing it on the server.
The public XEPs only cover use cases which are generic and where other people deploying chat services based on XMPP can also use them. So, if your chat needs a specific functionality, we're always happy to help.
We also have projects where MongooseIM replaces another XMPP server. This is common when clients discover that the MongooseIM alternative technology they have chosen did not meet their expectations. A common reason for this is that out of the box functionalities can turn out to be black boxes that make it impossible to carry out necessary customisations or improvements.
Another common reason to switch to MongooseIM is to improve scalability when an existing solution reaches its capacity. In this case, we play the role of surgeons, carefully implementing a transplant to put MongooseIM at the heart, improving scalability but keeping the rest of the system running smoothly.
Tips to avoid common mistakes when using open-source MongooseIM:
Choose your XEP, and choose wisely.
X in XMPP stands for eXtensible. This means it might not be the simplest protocol, but there's hardly a chat feature it doesn't cover. There is a set of core RFCs on top of which custom extensions (XEPs) are built. There are usually no issues with the core functionality that is covered in RFCs. They are adopted by many client libraries and servers. XEPs are often isolated from each other, independent from the core functionalities. They add extra features or capabilities to the core of XMPP. Here comes the biggest challenge: deciding which XEP to choose (you can find more details in our XMPP use-cases guide). From our experience, developers starting their adventure with XMPP may have a hard time finding a suitable XEP. This can sometimes accidentally lead to your choice creating difficulties or limitations. Some examples:
Too many extensions are enabled on the server-side, but not used by the client app.
Certain XEPs like XEP-0012: Last Activity put extra load on the server, even when the client's application is not using them. Enabling only used extensions helps to scale the MongooseIM cluster.
An outdated or rejected extension is used.
Often, different products with instant messaging functionality store the messages on the server. For this, there is extension XEP-0313: Message Archive Management. The majority of servers and client libraries have implemented the XEP for several years already. It replaces an old, more complicated and now deprecated XEP-0136: Message Archiving. Sometimes, developers choose the deprecated extension over the new one.
A custom extension is built even if an existing XEP covers the required functionality.
For instance, if a user wants to know if someone is active in a chat conversation. To achieve that, some extra XMPP stanzas need to be sent. Developers, me included, are creative creatures, and sometimes we rush to reinvent the wheel. In this particular case, XEP-0085: Chat State Notifications fulfils this need.
Reduce unknowns
When preparing for a wave of users using instant messaging functionality, we need to remember to load test. It's very crucial to run load tests to know the capacity of your production setup. To my surprise, this is often neglected. Many people want an answer to the following simple question: "how many resources do I need to handle X number of users, sending Y messages per second". There are too many factors and variables to accurately answer this question. To have a better idea about the capacity, you can run load tests simulating user behaviours. It usually starts with developing the scenario. After making sure that monitoring is in place, the load testing can start. Now we can learn how the system behaves and what to expect in the production environment.
Summing it up
It is very important:
- to know what functionalities are needed and enabled on the server
- to verify if a custom extension is already covered in a XEP
- to only build a custom extension if necessary
- to run load tests to find the capacity and be better prepared for the real traffic
All of the above may not be rocket science; many services run on MongooseIM without our help.
If you are up to the challenge, good, we are always happy to see our product in use.
But, when your time is critical, or if you stumble upon a problem you can't fix, we're happy to help. If hacking through 80K lines of unknown code is not your cup of tea, we can guide you through it. Stay safe and have fun adding real-time communication to your product, if required.
Top comments (0)