Talk to our team

Explore Uplyst

Esc

Popular places to start

platformEnterprise intelligence for the way you work.

Uplyst connects operational data, business relationships and real time events to support decisions across your enterprise.

integrationsConnect your enterprise systems.

Explore Uplyst integrations across business applications, data platforms, databases, event streams and industrial systems.

DocumentationTechnical guides for connected systems

Guides to enterprise architecture, semantic models, integration contracts, security and operations.

resourcesEnterprise intelligence in practice

Architecture, integration and governance guidance for connecting enterprise data with operational decisions.

WebSocket streams and session recovery

WebSocket supports two way communication over a persistent connection. Applications still need a protocol above the transport for subscription ownership, message validation, flow control and recovery after the connection disappears.

Review session recovery
Example: restoring an invoice subscription
Connection after reconnectOPEN

The connection is open. Check access before restoring the invoice subscription.

Requested resourceinvoices/inv_1042
Still authorized

Restore the subscription

Validate the cursor, replay any retained events and refresh the view.

Access revoked

Deny the subscription

Do not send invoice events after access has been revoked, even if the connection is open.

Separate transport from application protocol

WebSocket provides an opening handshake and message framing over a connection. It does not define invoice subscriptions, delivery acknowledgements or event replay. Choose it when frequent communication in both directions supports the product experience, and define those higher level behaviors deliberately.

RFC 6455 requires client frames to be masked and server frames to be unmasked. Maintained WebSocket implementations handle these framing details. Application code should focus on its message contract rather than implementing a new frame parser or treating framing compliance as a complete security design.

Authorize connections and subscriptions

Use a secure transport and an explicit browser authentication strategy. Validate the Origin header against the browser application's allowed origins where applicable. Origin validation helps control browser initiated requests, but it is not a replacement for authentication because other clients can supply their own headers.

Authorize each subscription against the current principal and permitted business scope. A connected client does not automatically gain access to every channel. Define what happens when a session expires or access changes: reauthorize, unsubscribe or close the connection with a documented recovery path.

Keep command and event messages distinct

Give client commands a request identifier so responses can be correlated without depending on arrival order. A subscription acknowledgement confirms the subscription state, not completion of a business action. Keep event identity and cursor information separate from a command's correlation identifier.

Validate message type, required fields and payload size before processing. Reject unknown commands predictably. Define subscription messages in the application protocol alongside success, rejection, unsubscribe and cursor expiration messages. WebSocket supplies the transport framing.

json
{
  "type": "subscribe",
  "requestId": "req_81",
  "resource": "invoices/inv_1042",
  "after": "cursor_2048"
}

An application subscription request with its resource and replay cursor.

Rebuild session state after interruption

A network path may fail without an immediate close notification. Define liveness using transport support or an application heartbeat with a bounded timeout. Browser applications cannot directly send protocol ping control frames through the standard WebSocket interface, so application heartbeat messages need their own documented meaning.

Reconnect with capped backoff and jitter, then reestablish authorized subscriptions. A new connection does not resume the previous application state automatically. When replay is supported, validate the cursor and its retention window; otherwise retrieve current state and make the reset visible to the interface.

Protect capacity and test recovery

Bound connection counts, message size and pending sends. Establish a slow consumer policy that matches the data: replaceable status updates can be coalesced, while business events may need durable storage and later replay. Report dropped or deferred work instead of hiding it behind a healthy connection indicator.

Test reconnect storms, expired sessions, malformed messages, duplicate subscriptions and abrupt server restarts. Verify that subscriptions are cleaned up when views close and that a client cannot subscribe outside its scope. Monitor queue growth and message age alongside connection counts.

References