What are WebSockets?
WebSockets is a technology that enables real-time, bidirectional communication between web browsers and servers. Maintaining the connection and exchanging messages as necessary empowers the client and server to converse. This is different from the conventional HTTP “request” and “response” models. Online games, real-time data updates, and conversation are just a few applications for WebSockets.
WebSockets Overview?
One of their best features is that WebSockets enable communication between the client and server. With WebSockets, each request necessitates a new connection, unlike conventional HTTP requests. A single link can be left open the entire time instead. Communication is sped up because it takes less time to establish and tear down connections.
WebSockets also benefit from letting people talk to each other in both directions. This means that both the client and the server can send and receive data simultaneously, something that can’t happen with regular HTTP requests. This feature is helpful for apps that need to be updated in real-time, like online games or stock market data.
Websockets allow clients and servers to communicate in real time and both ways. It keeps the client and server connected instead of starting a new connection for each request, like HTTP does. WebSocket connections allow clients and servers to exchange data in real time without reconnecting. Real-time data streaming, conversation, and games employ websockets.
HTTP and WebSockets send and receive data in various ways and for different types of data.
Websockets use cases
Websockets can be used in many different ways. Here are some of the most popular:
Real-time chat apps: WebSockets can be used to make chat apps that let multiple people talk to each other simultaneously. This technology is perfect for chat apps because it will allow for low-latency communication, which means that messages will be sent and received almost immediately.
Online gaming: WebSockets can be used to make smooth and responsive multi-player games that can be played online. It lets players talk to each other and the game in real time, making it more fun.
Streaming real-time data: WebSockets can stream real-time data like stock market data, weather information, or updates from social media. This technology is excellent for streaming data, which means that data is sent almost instantly.
IoT (Internet of Things): IoT devices can be connected to a server or a cloud service using Websockets.
Tools for Working Together: WebSockets can be used to work together. For example, multiple people can work on the same Google Doc simultaneously. Websockets allow users to talk to each other quickly, so changes made by one user show up almost immediately on the screens of other users.
Push Notifications: WebSockets can be used to tell the client about new emails, new messages, or changes in stock prices in real time.
Live Streaming: WebSockets can be used to stream live video and audio in real-time, such as live concerts, live news, or live sports.
These are just a few of the many ways WebSockets can be used. It is a flexible technology that can be used in many ways because it can keep a single connection open for real-time, two-way communication.
WebSockets vs Messaging vs Event Streaming
| Criteria | WebSockets | Messaging | Event Streaming |
| Usability | Two-way communication between the web server and the Client | Asynchronous communication between applications | Real-time processing of events (change in state) |
| Data Type | Supports both text and binary data | Not optimised for binary data | Not optimised for binary data |
| Security | Out-of-box encryption using WSS Custom implementation for authorization. | Out-of-box encryption and authorization. | Out-of-box encryption and authorization. |
| Performance | Low latency due to persistent connection between Client and Server | Higher latency due to the presence of a Message Broker | Improved performance compared to messaging |
| Availability and Scalability | Normal measures are taken for a Web Server | Separate measures required for the Broker | Separate measures required for the Broker |
| Additional Components | None | Message Broker like ActiveMQ | Brokers like Kafka or Solace |
| Additional Cost | None | Licence, subscription, and maintenance costs for brokers | Licence, subscription, and maintenance costs for brokers |
The guide to selecting the right real-time data transmission technology – webSockets, Messaging, and Event Streaming
Choose websocket if your requirements are
- There are multiple types of data, mostly binary data, that need to be sent back and forth.
- Speed up data transmission.
Choose messaging if your requirements are
- High-end security.
- Built-in presence and messaging functionalities.
Choose event streaming if your requirements are
- Real-time processing and analysis of state changes.
- Send each event to multiple consumers.
- Access to message history
WebSocket design pattern using MuleSoft
When building applications with WebSockets, there are a few common ways to do things:
Publish-Subscribe: This pattern lets clients subscribe to specific topics or channels and get updates in real time when new data is added to those channels. This is often used to build real-time notifications, chat systems, and other apps where more than one client needs to know the same thing.
These are some of the most common design patterns. More complex design patterns can be used, depending on the use case. When building WebSocket-based apps, it’s also important to think about scalability, security, and how to handle errors.
As a result of the following API-led connectivity:
- The System Layer is responsible for getting data from Upstream systems like File Systems, Databases, Message queues and topics, Third-Party applications, etc.
- The Optional Process Layer is responsible for necessary transformation, business logic, and/or orchestration.
Experience API is responsible for publishing the data over WebSocket
- To connect to a WebSocket endpoint, consumers must first register themselves by invoking the POST/consumers endpoint and sending valid credentials. A consumer must re-register if it disconnects after a configurable time (Mule default: 30 days) from the last connection.
- The endpoint responds with a token in JSON. The token persists in the cache or database against the client_id.
- Consumers pass the token in the header to a new WebSocket connection with the server (Experience API in this case).
- The WebSocket Endpoint validates the token received in the header with the one that the endpoint or consumers generated.
- The WebSocket connection is established if both token values match. The WebSocket ID is updated against the client_id in the cache or database.
- The Experience API leverages the WebSockets Connector (Mule 4).
Non-Functional requirements
Non-functional requirements (NFRs) are software requirements that tell how a system should work or act instead of what it should do. They are often used to describe the qualities of a system, like how well it works, how safe it is, how easy it is to use, and how easy it is to fix.
These non-functional requirements are important for a software development project to go well. They should be taken into account and given priority alongside functional requirements during the design and development process.
- Security, Known Risk, and Issue
- Error Handling
Security
- POST/consumers: Secured by the Client_ID_Enforcement Policy.
- POST/entity: Secured using an IP allow list with VPC CIDR as the allowed IPs so that only System API can consume it.
- WSS /ws/publish: Anypoint Platform doesn’t allow to apply policy on a WebSocket endpoint. The WebSocket endpoint is secured using token validation, as explained in the previous section.
- All the REST and WebSocket endpoints are exposed over either HTTPS or WSS. The required certificate and keystore configuration can be done at Dedicated Load Balancer or Listener in the app.
- If a consumer tries to connect using the same token and client_id while an active connection is established, the Experience API drops the duplicate connection request.
Known risk and issue
Known Vulnerability:
The approach of token validation is vulnerable to a DDoS attack for a few milliseconds when the Mule flow (on-inbound connection) is validating the token. An attacker can flood the WebSocket endpoint with requests containing bogus or no tokens.
In such an event, no data breach happens, but the application may become non-responsive and require a restart.
Known Issue:
The WebSocket endpoint expects custom headers in a new connection request. Browsers and JS frameworks have a limitation wherein they can’t send custom headers. However, Postman and Java libraries can send headers in a new connection request.
Error Handling – Experience API
| Error Scenario | Proposed Handling |
| WebSocket Consumer disconnects | Remove the WebSocket ID associated with the client ID. |
| Error on new WebSocket connection (E.g., invalid token) | Stop the flow Log the error Close the WebSocket connection. Send an Email Notification to the DevOps Team |
| A WebSocket consumer sends a message. (If not allowed) | Respond that consumers are not allowed to send messages. Log that the consumer (incl. Client ID) is sending messages. Close the WebSocket connection and remove the WebSocket ID associated with the client ID. Send an Email Notification to the DevOps Team |
| Any other internal errors | Stop the flow Log the error Send an email notification to the DevOps team. |
Error Handling – System API
| Error Scenario | Proposed Handling |
| Mule disconnects from the source system. | Mule App retries to connect for a certain number of times (configurable). If the retry fails, log the error and send an email to the DevOps team. |
| Unable to connect to Experience API | Log the error Send an email notification to the DevOps team. |
| Any other internal errors | Log the error Send an email notification to the DevOps team. |
