Introduction

For a chat application data delivery to clients (end-user devices) in real time is a crucial aspect. Several protocols and systems have been developed to provide the functionality over various layers in the OSI (Open System Interconnections) model. While developing our in house models for chat’s real time component we leveraged Google’s Firebase. As the system grew complex with more layers of functionality to be added like presence detection, delivery reports etc, we tried to look for a more tailor made solution for chat and real time. This document presents the options explored and choices made.

XMPP

XMPP (eXtensible Messaging and Presence Protocol), a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalised routing of XML data.

‍

XMPP was originally developed in the Jabber open-source community to provide an open, decentralised alternative to the closed instant messaging services at that time providing features over and above the existing ones,

• Readily Available - the XMPP protocols are in public domain with multiple implementations in the form of clients, servers, server
  components, and code libraries.
• ‍Industry Proven - hundreds of developers are working on these technologies, there are tens of thousands of XMPP servers running on
  the Internet today, and millions of people use XMPP for instant messaging through various public services and XMPP deployments at
  organisations worldwide.
• ‍Decentralised - the architecture of the XMPP network is similar to email hence, orgs can implement the communication infrastructure for
  their requirements.
• ‍Secure - robust security using SASL and TLS has been built into the core XMPP specifications. In addition, the XMPP developer
  community is actively working on end-to-end encryption to raise the security bar even further.
• ‍Extensible - using the power of XML, custom functionality can be built on top of the core protocols
  

‍
WebSockets

WebSocket enables bidirectional, full-duplex communication between client and server over a persistent, single-socket connection. The intent is to provide what is essentially an as-close-to-raw-as-possible TCP communication layer to web application developers.

The WebSocket has broad applicability. We can use it for different purposes, such as streaming data between backend services, or connecting a backend with a frontend via long-lasting, full-duplex connections. In a nutshell, WebSockets are an excellent choice for architecting event-driven systems and building realtime apps and services where it’s essential for data to be delivered immediately.

‍
We can broadly group WebSocket use cases into two distinct categories:

• Realtime updates - where the communication is unidirectional, and the server is streaming low-latency (and often frequent) updates to the client, like live sports updates, alerts, realtime dashboards, or location tracking, to name just a few use cases.
• Bidirectional communication - where both the client and the server can send and receive messages. Examples include chat, virtual events. WebSockets can also be used to underpin multi-user synchronised collaboration functionality, such as multiple people editing the same document simultaneously.

And here are some of the main benefits of using WebSockets:

• Improved performance - Compared to HTTP, WebSockets eliminate the need for a new connection with every request, drastically reducing the size of each message (no HTTP headers). This helps save bandwidth, improves latency, and makes WebSockets more scalable than HTTP.
• Extensibility - Flexibility is ingrained into the design of the WebSocket technology, which allows for the implementation of subprotocols (application-level protocols) and extensions for additional functionality.
• Fast reaction times - As an event-driven technology, WebSockets allow data to be transferred without the client requesting it.

‍
LikeMinds Use case

LikeMinds is a chat and Feed SDK product. We wanted to introduce components which adhere to our requirements i.e. ease of setup and scale, extensibility and flexibility to stack new features. While XMPP is an application layer protocol designed for chat requiring a transport for delivery of payloads over the network such as TCP/IP, HTTP or even WebSockets, WebSockets enable a close-to-raw TCP communication.

Protocol Comparison

We did a comparison between the two protocols to find the best fit for our use cases and compared the richness and powerful features offered by the two and know restrictions to make an informed choice.

‍

Based on the comparison, both seems a strong choice with their own powerful features and limitations combined to deploy a real time chat application. We need to decide on our own criteria and considerations and do a POC to make a decision.

LikeMinds Considerations

We made a list of considerations applicable wrt to our current requirements, scope of features and future spec and scale path to compare the two. The consideration objectives and how XMPP and WebSockets response to those objective is listed below

POC

XMPP

We did a POC on XMPP using ejabberd server setup which is an Erlang implementation in jabber protocol for chat application and presence

WebSockets

We did a POC on WebSockets by developing small micro service with aim to replace real time delivery of chat message data from Google Firebase to our own WebSocket based implementation in Go.

Choice

We went ahead with WebSockets based implementation for its speed (reduced latency), performance, high concurrency, and dataintegrity. We were able to design and add new features like delivery reports, presence (in progress, design ready), typing indicators (inprogress, design ready) with relative ease and complete control over tailored requirements. We plan to migrated existing and add newfeatures from chat and feed both over the WebSockets.