What is WebSocket Protocol and how to use it in Hybrid Cloud Environment?

What is WebSocket Protocol and how to use it in Hybrid Cloud Environment?

In this article, I will explain how WebSocket technology can enable bi-directional communication in real-time using a hybrid cloud environment leveraging AWS WebSocket in API Gateway.

What is WebSocket and How is different from HTTP?

Before we go deeper into the usage, let’s understand what is WebSocket and how it is different from HTTP protocol, and even why it is needed.

Traditionally, for any client-server communication — we use HTTP or HTTPS protocol. The HTTP protocol is a unidirectional protocol that works on top of the TCP protocol which is a connection-oriented transport layer protocol, connections are created using HTTP request methods after getting the response HTTP connection gets closed.

What if we need to keep the connection open to constantly receive requests from the server in a bi-direction way? — The answer is WebSocket

WebSocket is bidirectional, a full-duplex protocol that is used in the same scenario of client-server communication, unlike HTTP which starts from ws:// or wss://. It is a stateful protocol, which helps to keep the connection between the client and server alive unless terminated by either party (client or server). After closing the connection by either the client or server, the connection is terminated from both ends. The connections are tracked using a unique connection id.

There are many use cases for WebSockets. A few of the examples are as below:

1. Gaming application — In Gaming applications users focus on the UI when playing games and they don’t or can’t refresh the screen to retrieve data from servers while playing (I can’t imagine the experience if gamers do the manual refresh). In such cases, Websocket technology helps in refreshing the data automatically without creating new connections.
2. Real-time feeds — In all the real-time web applications WebSocket is used to display data on the screen which is continuously sent by the backend server. The data is transmitted to the same opened connection which helps in establishing faster and more reliable data transfer with improved performance. Some examples are live matches and trading websites.
3. Chat Applications: Chat apps use WebSockets to establish the connection for exchanging, publishing, and broadcasting messages between subscribers by using the same connection.
4. Online Education: Online education portals use WebSocket for chat, text chat, and collaborative drawing on digital communal chalkboards.

There are many other use cases like collaborative editing, clickstream data, and location-based apps. Another use case is — how can we get real-time data in the hybrid cloud where some of the applications are on-prem, some are in the public cloud while few solutions are built into the SaaS platforms or we have a real customer looking at the data, seems complicated ??

Let’s see how WebSocket works in a typical Hybrid Cloud environment…

Scenario — Consider users accessing the application’s data using an Omnichannel experience (i.e, mobile, web, SaaS platforms, or B2B app). They are making changes to the application data, and if data is changed for any experience then it should be reflected for all the experiences. On top of it, the application is also seeing data change at a scale from on-prem applications using batch jobs or by user action in an async manner then that data should also be available to Omnichannel experiences in real-time.

Now, if we wanted to solve the above business problem using HTTP then I do see the following challenges:

1. We may not get real-time data in all experiences
2. Users will have to refresh the data manually but they don’t have any idea when to refresh manually
3. If we try to solve it using event-driven architecture and a combination of processes using HTTP (REST APIs) then we are designing an overly complex system.

Thanks to Ian Hickson and Michael Carter who developed the WebSocket protocol which was standardized by the IETF in RFC 6455 in 2011.

Also, if you are using AWS Cloud then implementation is even easier as AWS announced WebSocket APIs in Amazon API Gateway in Dec 2018. (see the below link for detailed AWS implementation)

About WebSocket APIs in API Gateway
In API Gateway you can create a WebSocket API as a stateful frontend for an AWS service (such as Lambda or DynamoDB) or…docs.aws.amazon.com

The above scenario can be solved using the 11 steps mentioned in the following architecture diagram:

1. The client application retrieves the token for making WebSocket API call
2. The client application initiates the WebSocket connection bypassing the authentication token retrieved in step # 1.
3. Once the request reaches to AWS WebSocket API Gateway then it invokes Lambda Authenticator
4. Lambda Authenticator connects to Auth Server to validate the token
5. Once the token is validated then AWS WebSocket API Gateway invokes the $connect the route to initiate the connection. ( API Gateway has three predefined routes that can be used: $connect, $disconnect, and $default. In addition, you can create custom routes.)
6. Once the persistent connection between the client and a WebSocket API is initiated then dynamoDb entry is created with connection information. Each connection has a unique id which can be stored with other metadata in the table for correlation and refreshing the data.
7. Now, assume there is a change event coming from an external system in async mode then the events will be captured in Kinesis firehose and will be fed to the “/sendMessage” route of WebSocket API Gateway. This is a custom route for receiving requests as an API resource.
8. This will send a notification to the client app to refresh the data by calling the API or retrieving the data from the source.
9. Client applications refresh the data on the screen without the user refreshing it.
10. If an API call is made then data is invoked by hitting the RDS instance via lambda.
11. Assuming, all the work is complete then the user closes the session which deletes the record from dynamoDb by invoking the $disconnect route. Please note, there is a $default route that exists on the WebSocket API which can be configured to cover “catch-all” type situations.

Conclusion: In this article, we have understood that WebSocket is a communications protocol for a persistent, bi-directional, full-duplex TCP connection from a user’s web browser to a server, and how it is different than HTTP. We have also seen various use cases for WebSocket and how it can be used in a modern hybrid cloud environment. Also, it is important to understand that if there is a need to retrieve data only once or we are good with old fetched data then we should go with HTTP protocol.

WebSocket is a very powerful protocol, and as the industry is getting matured and there is a huge demand to see real-time data, I am sure more use cases will be emerging to help users !!!