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.