WebSockets are used for real-time communication between the browser and a server. These communications are bi-directional. Therefore it fits low latency applications such as chat, real-time multiplayer gaming, in-app notifications.

If you are new to WebSockets, I suggest you look at the below article I’ve written to understand better how it works.

However, in this article, I will be looking at 4 key patterns when using WebSockets in practice.

• Sending messages directly.
• Triggers only.
• Single publisher and multiple subscribers.
• Multiple publishers and subscribers.

1. Sending Messages Directly

When a WebSocket connection is open between a client and a server, it is considered a full-duplex connection. The data flow is bi-directional.

Keeping the connection open and directly sending messages/information over the link is typical when implementing WebSockets.

For example, let’s look at a chat application such as WhatsApp. The moment someone sends you a message, you receive it on your phone or desktop application. You can also respond to this message instantly, which will be sent and received in real-time.

Using this pattern will require the server to keep a WebSocket connection open all the time. Then, if the connection fails, the client is supposed to re-establish the connection with retry logic.

Pros of sending messages directly

• Instant updates and transports all the information in an update.
• The client does not have to poll the information. The server can send the data, and it will be available for the client instantly — Fast delivery

Cons of sending messages directly

• Requires an active connection all the time. Therefore it require more server resources.
• With an always active connection, more resources are utilized on the client’s end too. For example, a mobile chat application with direct message and open connection will drain the mobile battery faster.
• Scaling and load balancing is hard, that requires a back-channel to scale out.
• Only suitable for applications with smaller payloads per message as sending larger payloads real-time would be very expensive.

2. Triggers Only

This pattern will only send notifications to the client when new data is available and “Not the data itself”.

For example, let’s say you have a dashboard to monitor orders for your e-commerce site. When a customer places a new order, your dashboard receives a notification saying, “You have one new order”.

Once you click on this notification, your dashboard (client) will send an HTTP request to the server to fetch the data for the new order.

The method is less expensive than sending messages directly, since smaller message payloads are sent from the WebSocket server.

This way, the always active connection will only be used for triggering notifications.

Pros of using triggers only.

• Less bandwidth required, less server load, and less expensive than sending all the information directly.
• There is a possibility of sending updates in batches where individual updates are not needed.
• It can trigger notifications such as for new updates that are not practical to send the payload along with the message.

Cons of using triggers only.

• Less real-time (delay involved) than sending all information directly as the information for the update is only fetched when requested for it.
• Not suitable for applications with smaller payloads (that we can send via the trigger) or those that require low latency for the entire information cycle.

Build & share independent JS components with Bit

Bit is an extensible tool that lets you create truly modular applicationswith independently authored, versioned, and maintained components.

Use it to build modular apps & design systems, author and deliver micro frontends, or simply share components between applications.

3. Single Publisher — Multiple Subscribers

The name suggests what the pattern does. For example, one publisher will be sending updates and multiple subscribers expecting to receive updates. This is done via events.

The publisher triggers the event, whereas the subscribers listen to the event.

This is similar to the pattern used for chat applications where more parties are involved.

Pros of using single publisher — multiple subscribers

• Ability to create applications (E.g., Whiteboards) for team collaborations with one presenter and many listeners.
• Won’t get concurrency issues that you need to handle at the application level.
• Send updates to many people in real-time.

Cons of using single publisher — multiple subscribers

• Only one publisher is allowed. Not suitable for team activity.

4. Multiple Publishers — Multiple Subscribers

This is a pattern that is enhanced from Single Publisher — Multiple Subscribers. Unlike the above pattern, many publishers are allowed when this pattern is used.

Therefore, this is suitable for applications that require team collaboration.

Pros of using Multiple Publishers — Multiple Subscribers

• More than one publisher is allowed. Suitable for team activity.
• Sends updates in real-time to all subscribed users and efficient for event communication.

Cons of using Multiple Publishers — Multiple Subscribers

• There will be a lot of event emissions. An active connection of the WebSocket needs to be maintained throughout the collaboration. So, require more server resources.
• Need to handle concurrency issues at the application level.
• Need efficient ways of persisting messages (e.g.: Stream processing).

Summary

We discussed several patterns that we can use when using WebSockets in practice. The correct method to use depends on your application requirement.

Before choosing the pattern to follow, you will have to weigh the pros and cons, analyze the resource utilization, and decide based on the criticality of real-time updates required.

Let me know which pattern you used in your applications in the comments section below. Thanks for reading!