Picking right messaging broker

I had implemented my last company (Plustxt) product over eJabbered. It worked well for couple of hundred thousand users but after I sold the company to Paytm and implemented for over 50+ million users, we immediately started noticing bottlenecks with scaling XMPP but also more importantly started facing heavy battery drainage in mobile. One of the most critical infrastructure for Glowing is also messaging broker. Inspite of great deal of knowledge sunk-in cost in eJabbered, we took the challenge of exploring for much better and reliable technologies.

Following were salient points we considered before picking the right solution:

  1. Ease of portability to platforms like having socket extension for web and MQTT for mobiles
  2. Lightweight
  3. Enterprise level message delivery, which would mean
    1. swift response
    2. for both device and web
    3. low latency
    4. no loss of message
    5. availability
    6. scalability
    7. eventual consistency
startups tech

Messaging aggregation platform and challenges

A messaging aggregation platform is a platform that is capable of receiving and sending messages to multiple (and popular) messaging platforms.  Existing messaging apps installed on user devices act as invisible apps available for and tie into our platform. Benefits for end (consumer) users who consistently rely and use a favorite platform include not needing to install any new apps, let alone change and learn new behavior; but rather, businesses that use a messaging aggregation platform merge into current habits and preferences of users.

startups tech

Localizing ReactJS static apps

Since we are so much focused on messaging layer, internationalisation and localisation is mission critical for us. We explored lots of solutions for incorporating messages for multiple languages but none of the solution worked out of box for us. After doing research, explored we need to zero down to one of the mentioned two options:

1: i18next
2: react-intl

Although both are complementary solutions with react-intl on first looked like eventual solution. But having different string messages for different languages looked like very hacky and react-intl was not infact made for that. Its mainly for localising formats (e.g., date). Also we are already using i18n on our API servers, so i18next looks like an apt choice for the workflow is similar. Here is how to integrate this i18next.