Improving push notifications with MongooseIM
--
by Michał Piotrowski
MongooseIM offers a completely customisable enterprise Instant Messaging solution. This helps large organisations build solutions that meet the unique requirements of their users. As a result, we’ve built many best-in-class instant messaging platforms for household names in social media, telecoms and the health industry. In our latest release, MongooseIM 3.6.0, we’ve continued to empower our application owners, and their end users by improving and evolving the push notification functionality. Find out more about how MongooseIM can build a bespoke instant messaging solution for your needs, or read on to find out more about the improvements to push notifications.
Creating a better Push Notification Experience in MongooseIM
MongooseIM is continuing its evolution to improve the user experience for mobile applications. Push notifications aren’t just a standard requirement for instant messaging applications; they are also one of the most used features for end-users. As a result, there is an increased need to have a seamless experience for both application owners and the user themselves. Push notifications were added to MongooseIM 3 years ago. The implementation was based on an XMPP extension XEP-0357: Push Notifications and a dedicated, standalone component called MongoosePush. Since then, we have been lucky enough to work with several customers using this functionality. We have also been given great feedback from our community including people who use MongooseIM, MongoosePush or both in their projects. We listened to them, observed their issues and decided to create a better experience in MongooseIM 3.6.0 and MongoosePush 2.0.
How has the MongooseIM end-user experience changed?
Push notifications are delivered when the server observes a message addressed to a user who is offline. What does this mean exactly? From the server perspective, it means that the user has no connected devices. This works well enough in cases where users only have one device and don’t use session resumption as described in XEP-0198: Stream Management. Today, this is not the most common use case when it comes to mobile applications. First of all XEP-0198 is used because it helps to make sure that stanzas are delivered from the server to the client and the other way around. What is also important to note is that mobile applications are not always active. People switch applications or put their phone down. In this case, the app goes into the background and the network communication is limited to save battery. This leads to a situation where a device may not respond to regular TCP communication (because it’s disconnected or in the background) and the server still thinks the user is online. Push notifications are often used to notify the user that there is new information for them to check, so it is important that the notification is delivered in seconds, not minutes. In order to solve the problem, MongooseIM 3.6.0 and later versions, can send push notifications to such user sessions which are in the “undecided” state. More technical details and information on how to configure this behaviour can be found in the push notifications documentation.
Fine grained push notifications priority control
Not all Push Notifications will have the same level of priority. Sometimes you will want to change the priority in order to have a different behaviour on the client device. Before MongooseIM 3.6.0 it was not possible to change the priority level, even though MongoosePush, which talks to FCM or APNS, has that functionality. In order to address this limitation, we decided to give the control of the priority to the application developer. Now the priority can be set while enabling push notifications. Take a look at the enabling push notifications documentation to see the possible values and the other options you can set while enabling push notifications.
How has MongooseIM changed from for the operator?
No PubSub
The other thing we learned from our users was that they always use MongooseIM as both the instant messaging server and the service responsible for sending push notifications. The XEP-0357: Push Notifications is very generic and allows you to configure a PubSub service responsible for delivering push notifications on a different server. This was not the case in all the installations we were aware of. Because of that, we decided to bypass the PubSub communication in a situation where we know MongooseIM is responsible for sending push notifications. This makes the MongooseIM configuration easier, with no need to configure the PubSub service. What is more important is that it reduces the load on the nodes and minimises delays in delivering push notifications. In the PubSub-less configuration, MongooseIM can talk directly to MongoosePush in order to deliver push notifications. This was implemented in a way that allows smooth migrations for older versions of MongooseIM where push notifications were already used in the full version. More details about all the possible setups, their advantages and drawbacks can be found in our push notification tutorial.
RDBMS backend
In production systems it’s more convenient to store persistent data in an external database. It makes life easier when it comes to clustering MongooseIM and using it in containers. One of the previous releases introduced an RDBMS backend for PubSub but this kind of backend was still missing for push notifications. Now we have it, so you can start storing all the details, passed from the app when enabling push notifications and required to deliver them in Postgres, MySQL or even MSSQL.
Inactive device id removed
The device ids (in other words device tokens you get from APNS or FCM) are not valid indefinitely. Generating push notifications to expired tokens doesn’t make sense and introduces unneeded load in the system. Thanks to integrating with MongoosePush 2.0 and it’s new API v3 for push notifications, MongooseIM can detect if a push notification was sent to a device token which is no longer active and remove it from its database. Thanks to that we eliminate stale data as soon as we know it is no longer useful.
MongoosePush 2.0.0
The last 6 months were also busy around MongoosePush development. It’s a standalone service written in Elixir. It exposes a simple HTTP (1.1 and 2.0) API which can be used to trigger push notifications to FCM and APNS. The recent version added support for new authentication methods to APNS, support for new FCM v1 protocol and unified error codes which allows for instances to detect if the device token is active or not.
More information can be found in MongoosePush 2.0.0 changelog and its documentation on GitHub esl/MongoosePush.
Other changes
Push notification improvements are not the only change in MongooseIM 3.6.0. Take a look at 3.6.0 changelog to learn more and give it a try and share feedback!
Help us improve the MongooseIM platform:
- Star our repo: esl/MongooseIM
- Report issues: esl/MongooseIM/issues
- Share your thoughts via Twitter
- Download MongooseIM 3.6.0 Docker image
- Download MongoosePush 2.0.0 Docker image
- Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
- Check out our MongooseIM product page for more information on the MongooseIM platform.
Originally published at https://www.erlang-solutions.com on February 10, 2020.
