Jan Mikoláš
Glossary
WebSocket
WebSocket enables live interface updates, but it does not guarantee delivery of a business event or replace server-side authorization.
Short definition
One open connection for messages in both directions.
WebSocket starts with an HTTP handshake in which the client and server agree to switch protocols. It then no longer follows the usual request–response cycle: the connection remains open and the server can send a message immediately, for example when a new order is created.
It is suitable for state that changes while a user is working. It does not, however, create a reliable queue or permanent event record. The connection can disappear, a message can be lost, and after coming back online the application must be able to verify the current state through a conventional API.
What it is used for
Where a live connection provides practical value
WebSocket is useful when the server needs to respond quickly and continuously, rather than waiting for the client’s next query.
- a live overview of new orders, payments, or inventory changes in an administration interface
- the status of a long-running import, export, or other asynchronous task
- chat, multi-user collaboration, or document editing with continuous changes
- operational monitoring and current alerts for internal system staff
- a complement to an HTTP API that still loads the complete, authoritative data state
Practical example
Subscribing to live events for a single tenant
After successful authentication, the administration interface opens a secure wss:// connection. The server identifies the user from the connection identity and, when a subscription is requested, verifies whether that user may read events for the specific organisation. A channel name sent by the browser is never proof of authorization.
After an outage, the client waits for increasingly longer intervals, opens the connection again, and loads the current order list through the API. This repairs any gap between the last message received and the state in the database.
JavaScript
const socket = new WebSocket('wss://app.example.cz/live');
socket.addEventListener('open', () => {
socket.send(JSON.stringify({ type: 'subscribe', tenantId: 'tenant-42' }));
});
socket.addEventListener('message', (event) => {
const message = JSON.parse(event.data);
if (message.type === 'order.updated') refreshOrders();
});How it works
Text diagram: client → HTTP upgrade → open connection → messages → state recovery
A network connection is only a transport path. The application must handle identity, permissions, ordering, and recovery after an outage separately.
- Connection over HTTPS The client opens a ws:// URL or, in typical production environments, a wss:// URL. The initial HTTP handshake requests an upgrade to WebSocket; the reverse proxy must support it.
- Identity verification The server verifies a session or another authentication mechanism. An open connection does not by itself prove that a user may read every channel.
- Topic authorization For a subscription, the server evaluates the tenant, role, and specific data. The same check applies to any message intended to make a change.
- Message transport Both sides exchange small messages. Ping and pong frames can help detect inactive connections, but do not provide business-level acknowledgement.
- Disconnection and return The client anticipates closure, retries the connection within limits, and synchronises any state it may have missed through the API after reconnecting.
Key concepts
Connection, channel, and acknowledgement have different meanings
Precise terminology helps design a system that behaves predictably even during outages.
Full duplex
The client and server can send messages independently. This differs from conventional HTTP, where the server typically responds only to a client request.
Channel or topic
The application can group events by organisation, order, or project. Such a name is merely an input to the authorization decision, not a security control.
Reconnect
After a disconnection, the client establishes a new connection, usually with a limited exponential backoff. The design must prevent a reconnection storm during a service outage.
Backpressure
A slow client or server may not keep up with incoming messages. The application therefore limits queue size, aggregates less important changes, or lets the client load the current state.
Coordination across multiple servers
With horizontal scaling, a subscriber and producer may be on different nodes. Distributing the event then requires a broker or another form of shared coordination.
Benefits and limitations
Lower latency in exchange for more complex operations and state recovery
Benefits
- the server can inform the client without waiting for the next poll
- one connection is enough for multiple related live changes
- better responsiveness for chat, monitoring, or administration interfaces with rapidly changing state
- it can be combined with an HTTP API without implementing custom long polling
Common mistakes
- assuming that a connected client will always receive every message
- trusting a channel name sent by the browser without authorization
- failing to handle reconnection, gaps in events, and loading the current state
- keeping unlimited numbers of slow connections or queued messages
- overlooking upgrade support, limits, and timeouts in the proxy or load balancer
When to use it
When a change must arrive quickly, not when an occasional query is enough.
For a public catalogue that changes a few times a day, a conventional HTTP cache or occasional reload is usually simpler. WebSocket is worthwhile when a user is actively watching a changing object and every new request would impose needless load on both client and server.
Simply sending a WebSocket message is not enough for critical integration events. A more reliable design persists the change, alerts the client, and allows it to retrieve the state or missing events through a documented API after reconnecting.
What to consider
A live channel needs the same security boundaries as an API.
The connection, every message, and recovery after an outage must all have a predictable contract.
- use wss:// and configure WebSocket upgrades correctly in the reverse proxy
- verify identity and authorize every topic and action on the server
- limit message size, subscription count, and sending rate
- design reconnection with backoff, state synchronisation, and observable errors
- measure connection counts, latency, closures, failed connections, and overloaded clients
Common questions
WebSocket without common misconceptions
Is WebSocket faster than HTTP?
It avoids repeatedly establishing requests and lets the server send a message immediately. Overall response time is still affected by the network, backend processing, message size, and client load.
Does WebSocket replace a REST API?
Usually not. An API remains suitable for retrieving current state, history, explicit commands, and recovery after disconnection. WebSocket can complement these operations with live notifications.
Does WebSocket guarantee message delivery?
Not at the level of business meaning. The connection can fail, so the application must design acknowledgements, deduplication, history, or state reloads according to the importance of each message.
Is authenticating a user only when they connect enough?
No. Authentication establishes identity, but the server must verify access to a tenant, channel, and specific data against current authorization.
How I design integration and application flows in practice
I connect live updates to authoritative state and a clear contract.
For systems involving orders, inventory, and integrations, I address not only the real-time message but also outages, permissions, traceability, and safe data recovery.