WebSocket or SSE

Choosing the Best for Real-Time Apps

Apps like social media-based chat, multiplayer games, social feeds, financial-based apps, etc. demand communication with their servers. To achieve consistent communication, pull architecture or push architecture is implemented between the client and the server. Our sample applications need consistent communication between the client and the servers. They demand push-based architecture and the options are WebSocket, Long Polling, or Server-Side Events (SSE). Implementing these technologies comes with its advantages and disadvantages. Usually application specific scenarios are the deciding factors for the respective implementations. Let’s dig into these scenarios for WebSocket and Server-Side Events.

WebSocket:

WebSocket is a connection-based communication protocol working in the Browser. WebSocket is messaged-based and implemented on top of the TCP to break down the coherent messages sent in a stream. This is used when the server needs to push data continuously. For example in the multiplayer game, a player is updated with each action performed by others. It is good to implement WebSocket in these scenarios.

1. The push mechanism of WebSocket avoids the burden on the server from unnecessary requests.
2. It avoids lag in the information. The notifications transmitted to all the connections are accurate and coordinated.
3. The server takes control and knows the exact connections at any given point of time. The server receives the notification of a drop in connections.

WebSocket is a promising technology to work with, but exhibits its limitations. For us, knowing these limitations are essential, to avoid reconsideration of other technology.

1. As long as the client and server understand the WebSocket protocol the direct communication between them is quite persistent. But, working with proxies and firewalls may be a bit tricky.
2. The number of client connections is dependent upon the capacity of the client’s network. If the client connection gets terminated, then it is not recovered automatically by WebSockets.

Server-Side Events (SSE) :

SSE are Server-Sent DOM Events, a prominent player in continuously streaming events in Opera. They are used in applications that display real-time data to users. The frequency of data exchange is not high but the notification of change is necessary. Applications like news updates, twitter feed, eCommerce platform, dashboard or live sports/stock price update, promotions of specific services send immediate notifications as the data change occurs in the server. Unlike WebSockets, SSE is mono-directional. A client that subscribes for a stream of a server, is sent an “event-stream” until the client or server closes the stream. As per the client’s subscription, the server decides what and when the event stream is sent.

Using SSE has many advantages:

1. The unidirectional communication protocol enables SSE to avoid server load.
2. They can easily handle the predefined standard error protocol and real-time data streaming using an HTTP-based method.

Being unidirectional also possess disadvantages:

1. The client is incapable of passing information to the server. But, as a workaround, the developers use query strings to communicate the client’s data.
2. Notification of lost connection between client and server is absent.
3. SSE works on UTF-8, lacks support for binary data and restricts to a maximum of 6 open connections.

Choose the best communication protocol:

Implementation of WebSocket in demanding applications requires an upfront input of developers and may demand full-duplex TCP connections. SSE is widely used to push the data from the server once the connection is established. Many times, SSE is an ideal solution for apps, but don’t consider it as a universal solution. Because of the nature of the Websocket being a 2 way communication protocol and our notification needed it to be a 2 way communication, we ended up choosing WebSocket over SSE. At BundleN, we experiment with stack combinations on our own time. For potential clients interested in this stack, we can always give a demo of what we have up until that point of time. You can reach us at sales@BundleN.com

For more details on this stack, click here

Here is the latest about our Angular + Java project.

Task

Add Interceptor to capture log events

Task Details

Add Java Interceptor to capture log events. Capture Case Information into the database. Add an event driven micro service to capture the request payload and inject that into the NoSQL database.

Task

Get the Response Status and the Response Payload

Task Details

Log the Response Status and Payload in the NoSQL database through an event driven micro service

Task

Develop UI page to display log activity

Task Details

Develop UI page to display log activity. Page should have the user info, request time, payload, response code, time and response payload.

Information should be filtered out at the server side based on who is requesting the information

WebSocket

Use WebSocket to push information to the client