Introduction to WebSockets

Addressing varying data processing times in a front-end web application

Imagine a data platform with a front-end web application that interfaces with end-users. Data processing times can vary significantly based on factors like data size or the complexity of transformations. How then do we ensure that the web app delivers a seamless user experience while maintaining efficient backend operations?

In a typical client-server architecture where web applications communicate with API endpoints, the API gateway’s timeout limitation poses a significant challenge. As timeouts are typically set to a maximum of 1 minute, it becomes crucial to find a solution that avoids undermining the users’ experience while ensuring optimal backend performance.

While asynchronous API calls may seem like a viable option, this method introduces the need for repetitive polling of another API endpoint to determine data readiness following transformations. In addition, as the web app scales, excessive polling burdens the server unnecessarily, resulting in performance issues like slow response times, disruptive timeouts, and increased costs. To efficiently address these challenges, we will explore how WebSockets can offer a better alternative to asynchronous API calls.

WebSockets

WebSockets are a communication protocol that facilitates persistent, bidirectional, real-time communication between a client and a server. Unlike HTTP, which operates on a request-response basis, WebSockets allows the server to send data to the client without the need for the client to initiate a request. This allows web sockets to be a particularly suitable choice for real-time applications such as chat systems, multiplayer games, and financial tickers. More importantly, timeouts are no longer a concern as the connection will remain active until either the client or the server terminates it. Figure 16 showcases the operational mechanism for WebSocket.

WebSockets operatae according to the following processes

Establish a connection and upgrading to the WebSocket protocol

To initiate WebSockets, the client and server must first establish a connection. The client sends a HTTP handshake request, incorporating a header that signals the intent to upgrade to the WebSocket protocol (HTTP Status 101). Upon receiving this request, the server responds with a HTTP handshake response, confirming the acceptance of the upgrade. This response contains a distinct header indicating the successful transition to a WebSocket protocol.

Sending and receiving data

Once the WebSocket connection is established, real-time data transmission becomes possible between client and server. Data is exchanged in frames consisting of a header and a payload. The header carries essential frame details, such as the length and type, while the payload holds the actual data to be transmitted.

Closing the connection

When either the client or server decides to terminate the WebSocket connection, a closing frame is sent. The recipient responds with its own closing frame, leading to the closure of the connection.

Architecture Diagram

In this section, we showcase two reference diagrams that utilize WebSockets. One architecture diagram focuses on internet-based implementations, while the other focuses on intranet-based implementations.

Internet-based implementation (AWS)

This architecture diagram creates an AWS API Gateway that operates at the regional level. AWS does not provide private endpoints for WebSockets, limiting its support to scenarios with internet connectivity. To enhance privacy and conceal the API Gateway endpoint, we can associate the API Gateway endpoint with a custom URL. For instance, if you own the domain example.com, you can associate the API Gateway endpoint with websocket.example.com.

In this setup, three connections are required to be established – one between the client and the API WebSockets, another between the API WebSockets and the frontend application, and a final connection between the API WebSockets and backend applicati ons. Once these

Some additional considerations that can be tailored to support your system end-to-end include implementing reverse and forward proxies for secure network routing, making the choice between using either EC2 or ECS to host the frontend application, as well as utilising other API Gateways or ECS for backend server hosting.

In API WebSocket APIs, it is important to be aware of three predefined routes during the implementation process: $connect, $disconnect, and $default. In addition, you would have the freedom to create custom routes based on your specific requirements.

$connect is triggered by API Gateway when a persistent connection between the client and the WebSocket API is initiated

API Gateway involves the $disconnect route when either the client or the server disconnects from the WebSocket API

The $default route is called by API Gateway when the route selection expression cannot be evaluated against the message, or if no matching route is found

If a matching route is found after evaluating the route selection expression against the message, API Gateway calls a custom route. The specific integration to be invoked is determined by the matching route.

These predefined and custom routes offer flexibility in handling various events and interactions within a WebSocket API through API Gateway. It is important to note that if authorisers are required, they can only be executed during the $connect route call.

Intranet-based implementation (AWS)

Some cloud service providers do not offer a private API Gateway for WebSockets. As such, an alternative solution involves creating self-hosted WebSockets using a compute resource like EC2. One approach is to install open source WebSockets such as socket.io on the server, allowing it to manage the WebSockets connection between your frontend and backend.

It is important to note that with this design, you will have to assume responsibility for managing the infrastructure hosting your WebSockets APIs, including tasks like patching and updating. However, this approach grants you greater control over your end-to-end system without the need to expose your WebSocket endpoints to the internet. This self-contained setup proves especially beneficial when your goal is to minimise potential vulnerabilities in your architecture by reducing areas of exposure.