Hi, In this blog, we will be looking into some of the critical concepts for designing the Chat System. Almost every one of us uses a chat app. Each app performs different functions and targets different people. Let's take an example, The top 3 chat system which comes to our mind will be WhatsApp, Facebook Messenger, and Discord. Although all these apps have a chat feature, They target different people and their performance differs.
So it's very important to know our exact requirements and target audience. So here are the few points to address before starting the design.
- We will be designing a chat app that will accommodate both one-one chat and group chat.
- The maximum size of the group chat will be 100.
- The app will be supported on both mobile and the web.
- The app is not considering any attachments. Will be just supporting the texts with a maximum of 10,000 characters. The attachment feature can be brought later when we stabilize the MVP.
- Supports multiple devices and has an online indicator.
- No encryption will be done. This feature can be added later.
- Chat history is preserved forever.
- A notification feature is included.
STEP 1: Building Blocks of Chat App
Every chat app revolves around two important entities, Sender and the receiver. To develop a high-quality application, we should have a basic knowledge of how clients and server communicates. In chat applications, clients do not communicate directly with each other. Instead, each client connects to the chat service, which supports all the features in the requirement. Fundamental operations include:
- Receive messages from other clients
- Find the right recipient for each message and relay that message to them.
- If the recipient is not online, hold the messages in the server till they are online
STEP 2: SELECTING THE PROTOCOL
Now, we know the server is the middleman between the two users to send and receive the message. When a client intends to send a message, it connects the chat service using one or more protocols. The selection of protocol is very important in the chat app since the communication between clients should be seamless. There should be no delay or refresh happening. Basically, it should be like talking to someone live, so we don't feel disconnected. Imagine a situation where you have to refresh every 1 second or 2 seconds to get the message. It will be frustrating right
HTTP is the strong protocol to use when communication is from client to server. In general, the communication which happens using HTTP protocol follows some rules. Clients send a request to the server and the server responds to it. In this case, will it work? When a client sends a message, the server should relay that message to the recipient (i.e) the server should initiate the connection to the client when it receives a message. Seems different right? Let's ease it out.
- The client sends a message to the chat service with the receiver's details
- Chat service receives it and when the receiver is online should relay the message to the receiver.
Part one where the sender sends the message to the client is straightforward using HTTP protocol. But what about the second part where the server relays these messages to the receiver client?
Let’s discuss the options available.
- Polling: In this method, the client will be sending the request to the server at regular intervals to check if they have any messages. A real-time example is if there is a clothing shop in your city that has very exclusive designs. You thought of buying a particular dress from there. But the dress is in demand and the stock is not available. If you visit the store every day to check if the dress is available then that is what the polling is. But this is not a very good option. The cost of travelling might be very high. The chance of the cloth having the dress is not known.
2. Long Polling: In this method, the only difference is server returns the response only when there is a message for that client or when the timeout is reached. To match the real case scenario, you can only return from the shop when you got the dress or the day is over whichever happens first. Otherwise, you will wait the entire day in the shop to buy the dress.
3. WebSocket: The WebSocket connection is initialised by the client. It is bidirectional and persistent. It starts its life as an HTTP connection and could be upgraded via some well-defined handshake to a WebSocket connection. Through this persistent connection, the server could send the updates to a client. Consider you are going to the shop for the first time and you made the deal with the shop owner, you have exchanged the phone number. Now when the dress arrives the shop owner will be able to contact you and give you your dress. If you want any other model you don't have to go again to the shop. You can just communicate via this phone number and get the updates, the owner can also call you and send the item. Basically, the communication will be bidirectional and the travel cost will be way less.
This telephone connection between you and the shop owner is what we are trying to achieve using a web socket. Communication is initiated using HTTP(First time) from the client and after upgrading via handshake (exchanging phone number) there will be a bidirectional and persistent communication between the client and the server.
Earlier we said that on the server side, HTTP is a fine protocol to use, but since WebSocket is bidirectional, there is no strong technical reason not to use it also for sending. The below diagram shows how WebSocker(was) is used for both sender and receiver side
In the next article, we will be diving more into the stateless, stateful services and third-party integration which will be considered for the chat app. Cheers till then.
