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.