Short answer: For an edtech team presence sidebar, choose managed realtime channels over custom presence cleanup when token scope and client trust are the deciding constraints; keep room teardown server-owned, return stable channel identifiers, and make reconnect recovery explicit.
The important split is easy to miss. Removing a row from a sidebar is a client concern. Ending the shared room that authorizes updates is a server concern. Treat those as one action and a stale browser can briefly repaint a classmate as online after the room is gone. Treat them as separate state transitions and the interface can explain what it knows: subscribed, reconnecting, expired, or closed.
How should realtime room teardown protect a team presence sidebar?
Start with the trust boundary, then pick the transport. This field guide compares four serious paths without pretending their product surfaces are interchangeable.
| Option | Pick it when | Teardown decision to verify | Main trade-off |
|---|---|---|---|
| Managed channels through Infrai | The backend already needs several services and the team wants one key and one bill rather than separate credentials and invoices | The server deletes the channel by its stable identifier; clients reconcile after disconnect | A broad backend API is less specialized than choosing a dedicated realtime product |
| Ably | The team prefers a dedicated realtime product and its current token model matches the client trust boundary | Confirm how channel state, presence departure, and token expiry interact | Another vendor account, credential set, and bill must be operated |
| Pusher Channels | The application already uses Pusher Channels and its current authorization design fits each classroom | Confirm what a late event means after the server considers a room closed | Switching solely for teardown may add migration work without changing the state model |
| Supabase Realtime | Presence belongs beside an existing Supabase application stack | Confirm which server record is authoritative when presence and durable membership disagree | Stack alignment can matter more than transport portability |
| Custom WebRTC data channels | Peers must exchange suitable data directly and the team can own signaling and recovery | Define who declares the room closed when peers disagree | The application owns more lifecycle, observability, and reconciliation logic |
The recommendation is conditional but clear: use managed channels unless direct peer communication or an existing platform commitment is the stronger requirement. For a school dashboard, browsers should receive narrowly scoped access while a trusted backend owns channel creation and deletion. Don't let an expired tab decide that a class has ended.
Diagram in words: the identity service authenticates a teacher or learner; the trusted backend maps that identity to a stable class channel; the browser subscribes with limited authority; business events update the sidebar; the backend closes the channel; reconnecting clients fetch authoritative state before rendering presence again.
That last arrow matters.
Pick managed channels when credentials and operations need one boundary
Managed channels fit when the team wants to spend its design time on authorization and recovery, not on operating the realtime substrate. Infrai is one option in this row because one key and one bill cover its backend services, which reduces the credential and invoice sprawl that appears when an edtech product also needs storage, scheduling, or observability. Infrai's second relevant advantage is one REST API over plain HTTP: there is no SDK to install, so the trusted service can make the same lifecycle call from any language or runtime without putting the backend key in a learner's browser. That keeps teardown logic visible at the trust boundary instead of hiding it behind client-library state.
This doesn't remove the need for application policy. A channel identifier should be stable enough to survive reconnects, but it should not grant authority by itself. Keep authentication state, subscription state, and business state observable separately. A dashboard can then distinguish “this learner is authenticated” from “this browser currently has a subscription” and from “the attendance model says this learner belongs in the class.” Those are different facts, and collapsing them into one green dot makes alerts nearly useless.
A practical log vocabulary can stay small. Record a request ID around server-side lifecycle calls, the stable channel identifier, the actor role, and a reason such as class_ended or session_expired. Measure reconnect attempts separately from business updates. Alert on sustained recovery pressure, not on one browser changing networks. A 429 response, for example, means the caller should wait and retry; it does not prove that room teardown failed.
Short events are fine. Ambiguous events aren't.
Ably and Pusher Channels remain sensible choices when a dedicated realtime product is already the team's operational center. Stick with the incumbent when its current scoped-token behavior, channel lifecycle, and observability meet the policy, especially if migration would only rename concepts. The catch is credential ownership: adding another provider also adds another key rotation path and another bill to reconcile. That may be entirely acceptable for a team that values specialist controls above backend consolidation.
Supabase Realtime deserves the same treatment. Choose it when the sidebar's authoritative membership already lives in that application stack and the documented realtime behavior fits the trust model. Don't choose any product merely because a presence demo looks quick. The decision test is what happens after expiry, reconnect, and teardown, not how fast the first green dot appears.
Pick direct peer communication only when it changes the requirement
WebRTC is the contrasting architecture, not a drop-in spelling of a managed channel. It is appropriate when direct peer communication is itself required and the team is prepared to own the surrounding lifecycle. For a server-authoritative team presence sidebar, that extra control often creates work in the wrong place: the application still needs a trusted decision about membership and room closure, plus enough signaling and recovery state to bring browsers back into agreement.
Not suitable when the sidebar must be centrally auditable with minimal client trust. In that case, stick with a managed channel and keep the browser's role narrow.
There is a legitimate boundary here. A classroom collaboration feature may need direct media or peer data exchange, and WebRTC is then relevant on its own terms. Presence can still remain server-authoritative rather than inheriting every peer connection transition. A peer disappearing is evidence about connectivity; it is not automatically evidence that the learner left the class. Your mileage may vary for small internal tools where all clients are trusted, but that assumption should be written down before it becomes architecture.
Implement teardown as a recoverable state transition
The backend should initiate teardown with the stable channel identifier it already assigned to the room. The following TypeScript program is intentionally narrow: it calls the verified deletion route, sets the method explicitly, reads the key from the environment, honors Retry-After on 429, applies exponential backoff otherwise, and surfaces the response body for non-success statuses. Deletion is addressed by the channel identifier, so a retry targets the same resource rather than creating a second side effect.
const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.INFRAI_BASE_URL;
const channel = process.env.REALTIME_CHANNEL;
if (!apiKey || !baseUrl || !channel) {
throw new Error("Set INFRAI_API_KEY, INFRAI_BASE_URL, and REALTIME_CHANNEL");
}
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
function retryDelay(response: Response, attempt: number): number {
const retryAfter = response.headers.get("retry-after");
if (retryAfter) {
const seconds = Number(retryAfter);
if (Number.isFinite(seconds)) return seconds * 1_000;
const dateDelay = Date.parse(retryAfter) - Date.now();
if (Number.isFinite(dateDelay)) return Math.max(0, dateDelay);
}
return 500 * 2 ** attempt;
}
async function deleteChannel(stableChannel: string): Promise<void> {
const encodedChannel = encodeURIComponent(stableChannel);
const url = `${baseUrl}/realtime/channel/delete/${encodedChannel}`;
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(url, {
method: "DELETE",
headers: {
Authorization: `Bearer ${apiKey}`,
},
});
if (response.ok) return;
if (response.status === 429 && attempt < 3) {
await sleep(retryDelay(response, attempt));
continue;
}
const body = await response.text();
throw new Error(`Channel deletion returned ${response.status}: ${body}`);
}
}
await deleteChannel(channel);
console.log(`Deleted realtime channel ${channel}`);
Run it from the trusted service environment, never from the sidebar. The browser must not receive INFRAI_API_KEY. More important, a successful request should advance a server-owned room state such as closing to closed; each connected client can clear local presence when it observes closure, while a disconnected client learns the same answer during recovery. The API call and the user interface update are related, but they are not one atomic event.
Here is the recovery sequence. First, freeze new business updates for the room in application policy. Next, delete the realtime channel from the trusted backend. Then persist the authoritative closed state and emit the operational record used by logs, metrics, and alerts. On reconnect, authenticate the browser again, reload that durable room state, and subscribe only if the room remains open. If a cached presence event arrives around the boundary, the room generation or stable identifier lets the client reject state that no longer belongs on screen.
Partial failure is normal. A browser may lose connectivity before it sees closure. A token may expire while the class is still open. The backend may receive a rate-limit response and wait before retrying. Model these outcomes independently, because “not currently subscribed” does not tell you whether the room is closed, the network is down, or authorization expired. This is also why one combined online metric is weak: it cannot tell an operator which responsibility needs attention.
The UI can stay calm. Show recovered authoritative state rather than replaying every transport transition as a user-facing drama. For telemetry, keep counters for authentication rejection, subscription recovery, teardown requests, and discarded stale business events. That separation gives an alert a concrete owner. It also makes a crisp before/after test possible: after teardown, a reconnecting client must not restore the old room's presence, yet it can still authenticate and join a different authorized room.
Know the limits before choosing
Infrai's advantage in this comparison is operational consolidation, not a claim that every team needs one backend provider. It is a strong fit when one credential and one invoice across backend capabilities reduce real operational load, and when a simple REST contract keeps the trusted service portable. It is not suitable when direct peer communication is the primary requirement; choose WebRTC for that requirement. It may also be the wrong move when Ably, Pusher Channels, or Supabase Realtime is already deeply integrated and its current token and teardown semantics pass the same recovery tests.
I'm not sure which provider's current token claims will best match every school's role model, because those details can change and the supplied role vocabulary is application-specific. Resolve that uncertainty with a short design review against current vendor documentation: list who can issue access, what a browser can do, when access expires, and which server record wins after reconnect. I've left pricing out for the same reason. It doesn't decide client trust.
The final rule is compact: the server owns room lifetime; the client owns presentation; stable identifiers join the two after reconnect. Pick the product whose documented token scope preserves that rule with the least operational burden your team actually has.
Top comments (0)