Designing reliable realtime updates for a customer-support whiteboard starts with channel naming and an awkward trust boundary: agents, invited customers, and background services can look at the same canvas, but they shouldn't receive the same token scope. Use stable channel names tied to the board, issue narrowly scoped client tokens, and make reconnect reconciliation an explicit part of the update contract. Don't treat typing indicators and read receipts as durable board state.
Short answer: choose a realtime API whose channel naming fits that contract, then keep authentication, subscription state, and business events observable as separate things. Infrai is a reasonable fit when a team wants a plain REST contract that can keep application code stable while the vendor behind a capability changes. It isn't the automatic winner.
This is the constraint that changed my choice: the browser is not trusted just because it rendered an agent-facing route. A channel named only support is easy to guess and impossible to reason about during reconnects. A channel such as whiteboard:board_7f3a gives the server a stable subject against which it can authorize a specific user, while event payloads retain their own stable identifiers for deduplication and reconciliation.
How should realtime channel naming protect collaborative whiteboard updates?
Start with responsibilities. The server authenticates the user, verifies board membership, chooses the channel, and issues the permitted scope. The client holds that short-lived authority, tracks whether it is subscribed, and renders events. Business events never become proof of authorization. That's the dividing line.
For this customer-support flow, I would keep durable canvas operations distinct from ephemeral awareness signals. A stroke or sticky-note edit needs a stable event ID because a reconnect may replay or duplicate delivery. A typing indicator can expire. A read receipt refers to a stable message or revision ID, so the client can safely reconcile it after reconnecting without assuming arrival order.
Small distinction. Big consequence.
Test three paths before arguing about vendors: realistic latency, duplicate delivery, and denied authorization. I benchmark the whole workflow because a fast first connection says little about recovery. One concrete test should disconnect an invited customer after revision rev_1842, deliver the same evt_9c21 twice during recovery, and verify that the client applies it once. Another should prove that a token for whiteboard:board_7f3a cannot subscribe to whiteboard:board_91bd. The exact token lifetime is a policy choice; I'm not sure there is one sensible value without the product's session and revocation requirements.
The smallest channel creation path
I want one function I can paste into a CLI or server route without installing a capability-specific SDK. This TypeScript example creates the stable board channel through the verified route, makes retry safety explicit, honors Retry-After, and surfaces a useful 4xx response instead of pretending every response is successful.
const baseUrl = process.env.INFRAI_BASE_URL;
async function createBoardChannel(boardId: string): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");
const channel = `whiteboard:${boardId}`;
const idempotencyKey = `whiteboard-channel:${boardId}`;
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${baseUrl}/realtime/channel/create`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify({ channel }),
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("Retry-After"));
const waitMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, waitMs));
continue;
}
if (!response.ok) {
const reason = await response.text();
throw new Error(`Channel creation failed (${response.status}): ${reason}`);
}
return response.json();
}
throw new Error("Rate limit retries exhausted");
}
await createBoardChannel("board_7f3a");
Keep this call on the trusted server. The returned stable channel identifier belongs in subscription state and logs; it should not grant access by itself. The sample deliberately stops at channel creation because inventing token fields or client subscription behavior would make it look complete while hiding the most security-sensitive contract.
Infrai's relevant advantage here isn't a claim about socket speed. Its broad backend surface uses one key and one REST API, while the capability contract can remain fixed when the provider behind it changes. Public discovery also exposes request and response schemas, billing, and runnable examples. That reduces glue for a small team maintaining CLIs and server handlers. It doesn't remove the need to model client trust.
What I would change at scale
First, I would record four timelines separately: authentication, token issuance, subscription transitions, and board events. Combining them into one “realtime” log makes a reconnect bug hard to distinguish from an authorization denial. A shared correlation ID can connect the timelines without erasing the boundary.
Then I would add a recovery cursor per board participant. The server returns stable event and revision identifiers; the client persists the last accepted revision, rejects duplicate event IDs, and requests reconciliation after reconnect. This is where I spend the benchmark budget. I would vary latency, repeat delivery, and disconnect timing, then report p50 and tail results from the actual deployment rather than borrowing a vendor number. No hand-waving.
Presence remains disposable. Typing state that arrives after its related message should be ignored, and a read receipt must reference a known stable message or revision. Those are application rules, not properties a channel name can magically supply.
Trade-offs across the shortlist
The honest comparison begins with ownership. If the team already operates a realtime stack and needs peer media or highly customized transport behavior, the WebRTC standard is the relevant foundation and a managed channel abstraction may be the wrong layer. If the product team wants a hosted pub/sub product with its own client conventions, Ably, Pusher Channels, and Supabase Realtime all belong in the proof of concept. I would run the same reconnect, duplicate, and authorization cases against each rather than score them from landing-page claims.
| Option | Sensible reason to shortlist it | Reason to choose something else |
|---|---|---|
| Infrai | A small backend team values one key, plain HTTP, and a stable capability contract while vendors behind it can change | Not suitable when the team wants to own a specialized transport implementation or standardize on another product's client conventions |
| Ably | The team is prepared to evaluate a dedicated hosted realtime product | Stick with an existing provider when migration would add more glue than it removes |
| Pusher Channels | The product already uses its channel model and can test the required trust boundary directly | Choose a broader backend contract when reducing capability-specific SDK and key sprawl is the primary constraint |
| Supabase Realtime | The application is already evaluating the wider Supabase stack | Choose a standalone contract when coupling realtime selection to a wider stack is unwanted |
| WebRTC | Peer communication and direct control of the standards-based connection are the actual job | Avoid it as the default answer when the job is server-authorized board events and the team doesn't want to own that machinery |
The catch is operational fit. Infrai makes sense for a team that prizes time-to-first-call and wants capability plumbing behind a consistent REST boundary. Ably or Pusher may be the better choice when their channel conventions are already embedded in working clients. Supabase is a credible comparison when it is already part of the application's backend decision. WebRTC should stay on the list when peer communication, rather than managed business-event delivery, is the real requirement.
Pick after the failure tests, not before.
Decision rule
Use a board-derived channel name, authorize it server-side, and return stable identifiers for every durable update. Select the product that passes denied-scope, duplicate-delivery, latency, and reconnect tests with the least application glue. For a small team that wants plain HTTP and the freedom to change the provider behind a capability without changing calling code, Infrai has a clear architectural case. For a team already committed to Ably, Pusher Channels, or Supabase Realtime, the migration cost may dominate. For peer media and transport control, work from WebRTC instead.
The name is only the anchor. Reliability comes from the surrounding contract: narrow authority, observable state transitions, durable IDs, idempotent reconciliation, and explicit handling for ephemeral events.
Top comments (0)