Websockets

Websockets

A websocket is a connection that stays open, so the server can send something the moment it happens rather than waiting to be asked.

Where to find it

Architect Panel → Background Messaging:

• Polling — the alternative, and usually the right one

Architect Panel → Integration & Connections:

• API Server — the server side

Against polling

• Polling asks repeatedly. Simple, works everywhere, and does work whether or not anything changed.
• Websockets hold a connection open. Immediate, no wasted requests, and a connection per user to maintain.

When it is worth it

Genuinely live interaction, where a delay of seconds is visible and matters:

• Chat and conversation.
• Several people editing or working the same thing at once.
• A live operational display where seconds count.
• Progress on something long-running.

When polling is the better answer

Almost everything else. A queue that refreshes every thirty seconds, a dashboard, a notification count — none of these need to be instantaneous, and polling is simpler to operate and degrades more gracefully.

The honest test is the same one as for polling: would somebody act differently if this were thirty seconds fresher? If not, a websocket is complexity for nothing.

Connections drop

The thing to design for. Networks change, laptops sleep, phones move between wifi and mobile data, proxies time out idle connections.

A dropped connection is normal rather than exceptional, so anything built on this needs to reconnect automatically and to catch up on what it missed while disconnected — not merely resume from the next message.

Say when it is not connected

A screen showing live data that has silently stopped updating is worse than one that never claimed to be live, because the viewer trusts what they are looking at.

Show connection state, and make a stale view visibly stale.

Corporate networks interfere

Some proxies and firewalls do not handle long-lived connections well, and will close them or block them outright. If your users are behind managed networks, test there specifically — it will work perfectly in your office and fail in theirs.

Have a fallback

Where the connection cannot be established at all, the application should still work — falling back to polling or to manual refresh. A feature that simply fails behind a corporate firewall is a feature those users do not have.

Worked example

An organisation uses websockets for chat, where immediacy is the point, and polling for its dashboards and queues. The chat interface shows connection state and reconnects automatically, fetching missed messages on reconnect rather than resuming blind — which matters, because half its users are on mobile.

Recommendations

• Use polling unless immediacy genuinely matters.
• Design for dropped connections — they are normal.
• Show connection state on anything claiming to be live.
• Test behind a corporate network.

Live Channels

A channel is a stream of updates about something — a record, a conversation, a queue — that a client subscribes to.

Where to find it

Architect Panel → Integration & Connections:

• API Server — the server side

Architect Panel → Security:

• Permissions — what a subscriber is entitled to receive

Subscribe narrowly

To the specific thing being viewed rather than to everything. A client subscribed to all activity receives a great deal it will discard, which wastes connection capacity and makes the client's job harder.

Channel scope is a security boundary

The point that matters most. A channel delivers data to a client, so what a subscriber may join is an access question — exactly like which records they may read.

Check entitlement at subscription and when sending, not only in the interface. A client that can subscribe to a channel it should not is a disclosure that the rest of your permission model will not catch, because the data never went through it.

Unsubscribe when the view closes

Otherwise subscriptions accumulate as somebody moves around the application, and by the end of the day one user is subscribed to twenty things they are no longer looking at.

Catching up after a disconnection

The part that is easy to get subtly wrong. On reconnect, resuming from the next message leaves a silent gap — the client missed updates and does not know it, so the screen is confidently wrong.

Re-fetch current state on reconnect rather than assuming continuity. Being briefly redundant is much better than being quietly stale.

Handle out-of-order and duplicate messages

Both happen on real networks. A client that assumes strict ordering, or that applies the same update twice, produces subtle errors that are miserable to reproduce.

Make updates idempotent where you can — applying the same one twice should leave the same result.

Do not send more than the client needs

A notification that something changed, with the client fetching detail, is usually better than pushing full records down the channel. It keeps messages small and means the fetch goes through your normal permission checks.

Think about volume

A busy channel with many subscribers multiplies quickly. A queue updating several times a second with fifty people watching is a great deal of traffic — consider whether a summary at intervals would serve the same purpose.

Worked example

A shared work queue subscribes each viewer to a channel scoped to their own team, checked at subscription. Messages carry only "the queue changed", and the client re-fetches. On reconnect it re-fetches everything rather than resuming, so a user whose laptop slept sees the true state rather than a stale one.

Recommendations

• Check entitlement at subscribe and at send.
• Re-fetch state on reconnect, never resume blind.
• Send a signal, not the data.
• Unsubscribe when the view closes.