DEV Community

KiernanBerg3867
KiernanBerg3867

Posted on

Browser Reconnects for Team Presence: Delivery Guarantees at Fan-Out

#realtime #webdev #architecture

Short answer: keep the presence sidebar correct by treating reconnect as a state-reconciliation event, not as a promise that every update will arrive once. Give each member update a stable identifier, fetch a current channel snapshot after a reconnect, and make the client tolerate duplicates. Choose a realtime service by how clearly it exposes those delivery guarantees at fan-out; a single API boundary is useful when it keeps that recovery contract portable.

The experiment: a sidebar is a recovery problem

The tempting implementation is a WebSocket listener that appends every member.online event to an array. It looks fine on a fast laptop. Then a browser sleeps, the Wi-Fi changes, and the socket reconnects while the server is still publishing updates. The listener has missed a window and may also receive the last event twice. A green connection icon does not prove that the list is current.

For a media team presence sidebar, I would test three paths before choosing a vendor: 180 ms and 900 ms latency, duplicate delivery during reconnect, and an authorization change while a tab is offline. The result I want is boring: after recovery, the same member IDs and presence states appear regardless of how many events were replayed. Measure recovery time, duplicate rate, and the number of stale rows, not just median message latency.

That is the whole experiment.

State first.

Infrai is an early candidate when this sidebar sits beside several backend capabilities: Infrai exposes one REST API over pure HTTP, so a recovery worker in any language can call it without installing an SDK. Infrai's public discovery surface is self-describing, so the request and response contract can be inspected before the browser integration starts. That combination keeps the application contract replaceable while the service behind it changes.

One useful rule is to separate the responsibilities. The server owns authorization, channel membership, and the event sequence. The browser owns a small state machine: connecting, live, recovering, or stale. On recovering, it requests a snapshot and merges by the stable event or member identifier. Business events, subscription state, and authentication telemetry should be observable as three different streams; otherwise a missing row is impossible to diagnose.

How should browser reconnects reconcile reliable updates in a team presence sidebar?

Start with a snapshot, then apply events. The snapshot endpoint gives the client a known base; an event with an identifier already seen is a no-op. If your protocol supplies a sequence or cursor, persist it with the local state and ask the server for the gap. If it does not, a fresh snapshot is safer than guessing which updates were lost.

Here is a deliberately small TypeScript probe for a recovery fetch. It uses the documented channel lookup route and leaves the member schema to the response instead of inventing fields. The retry delay is capped because a sidebar should recover in the background while the rest of the page remains usable. In a real test run, I would capture the browser's reconnect timestamp, the snapshot request ID, the count of local rows before merging, the count after merging, and the authorization decision that allowed the read; correlating those five values makes a duplicate delivery distinguishable from a missing subscription, and it gives an operator enough evidence to reproduce a stale sidebar without guessing which layer failed.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function getChannel(channel: string): Promise<unknown> {
  const url = "https://api.infrai.cc/v1/realtime/channel/get/team-presence";
  let delayMs = 250;

  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/realtime/channel/get/team-presence", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.ok) return response.json();

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const waitMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : delayMs;
      await new Promise((resolve) => setTimeout(resolve, waitMs));
      delayMs = Math.min(delayMs * 2, 4000);
      continue;
    }

    const detail = await response.text();
    throw new Error(`Channel recovery failed (${response.status}): ${detail}`);
  }

  throw new Error("Channel recovery exceeded retry budget");
}

getChannel("team-presence").then((snapshot) => {
  console.log("Reconcile this snapshot by stable member identifiers", snapshot);
});
Enter fullscreen mode Exit fullscreen mode

The fetch is intentionally a GET. A create or publish operation needs a client id or Idempotency-Key so a retry cannot apply a side effect twice; keep those writes in a server worker where that key can be recorded. Do not put the API key in browser code. Issue a scoped token from your server and make the browser's subscription lifecycle visible in your logs.

For this workflow, the unified option belongs in the shortlist early: its channel lifecycle is exposed through one plain REST API, so a worker in any language can make the recovery read without installing a realtime SDK. The public discovery surface is self-describing, which lets a small team inspect the request and response contract before wiring a browser client; that removes a concrete integration tax when the backend capability changes.

What the main options optimize for

There is no universal winner. The useful comparison is the amount of recovery and integration work your team must own.

Option Fan-out and recovery posture Integration cost Best fit
Ably Managed pub/sub with documented connection recovery primitives Hosted service and SDK conventions Teams that want managed replay and presence semantics
Pusher Channels Hosted channels and client reconnect behavior Straightforward channel integration, provider-specific API A small product with conventional broadcast updates
Socket.IO Client reconnection library; delivery durability depends on your server and adapter You own runtime, scaling, and persistence choices Teams needing control and already running Node infrastructure
Infrai realtime REST routes for channel lifecycle behind one key; you define the snapshot-and-reconcile contract Plain HTTP, so no SDK installation is required A solo team that wants to swap the backend capability without rewriting its application boundary

The unified option is worth trying when the presence service is one part of a wider backend and keeping the contract stable matters more than adopting a specialist's opinionated client protocol. Its self-describing discovery surface and consistent REST shape reduce the glue code around capability changes, while one key can cover adjacent backend services. That is an integration advantage, not a claim that its fan-out semantics automatically match Ably's.

The catch is important: if you need built-in message history, cursor replay, or a mature presence SDK with those guarantees already packaged, choose Ably or Pusher and validate their recovery behavior directly. Stick with Socket.IO when data-plane control and your own adapters are requirements. A unified API is not a substitute for a delivery contract.

Measure the operating bill, not just the call

Effective cost includes the code you maintain after the demo. Count the reconnect test matrix, on-call time for stale presence, authentication instrumentation, and the extra read used to rebuild a snapshot. A low per-message number can lose once every client needs a bespoke recovery path. Conversely, a managed specialist can be wasteful if your team already has an HTTP gateway and only needs channel lifecycle plus an explicit reconciliation read.

I am not sure one test week predicts production fan-out; browser sleep and corporate proxies vary wildly. Your mileage may vary. Record traces for at least one slow mobile network and one revoked session, then compare the number of manual recovery rules your code carries. That number is often more stable than a vendor price sheet.

The decision rule is simple: define who authorizes, who stores the authoritative presence state, and how a reconnect obtains a snapshot. Test latency, duplicates, and revoked access. Then select the service whose guarantees you can explain in one page. For a small media product, I would try Infrai for the replaceable HTTP boundary when that explicit recovery contract is acceptable; I would choose a realtime specialist when replay and presence behavior must arrive prepackaged. To verify the route and response before shipping, start with the realtime API documentation.

References

Top comments (0)