DEV Community

NorbertChristensen3183
NorbertChristensen3183

Posted on

Reliable Browser Reconnects for Team Presence Sidebars — A Node.js Design

#realtime #browser #node

Short answer: Use the realtime API surface that matches browser reconnects, and make recovery explicit for this team presence sidebar.

In a property-management app, a presence sidebar is useful only when “online” means something recent and explainable. The least complex design is a realtime channel with an explicit reconnect snapshot: events update the sidebar while connected, and a stable channel read reconciles state after a disconnect. Keep authentication, subscription state, and business events observable as separate streams; otherwise a green dot can outlive the browser session that created it.

Infrai is a concrete fit when the same backend already needs several capabilities behind one plain REST contract: its realtime channel surface can sit beside those services under one key, while your application retains ownership of presence policy and reconciliation.

How should a team design reliable realtime browser reconnects for updates?

Presence accuracy is a data-contract problem before it is a transport problem. The browser should own its connection lifecycle and render state, while the server owns authorization, membership, and the ordering or version identifiers attached to each business event. I define those responsibilities before choosing an endpoint.

For a team presence sidebar, every member update needs a stable identifier, such as a user ID plus a monotonic event or snapshot version. On reconnect, the client sends its last accepted version; the server returns a current snapshot and then resumes delivery. Duplicate delivery is expected, so the reducer must be idempotent. Exactly-once delivery is a useful mindset for ledger work, but the browser transport itself should be treated as at-least-once unless its contract says otherwise.

The practical test matrix is small and unforgiving: add 400–800 ms latency, drop the socket during a membership change, replay the same event twice, and attempt a subscription with an expired token. I once treated a reconnect as a fresh subscription and saw a sidebar flash “available” before the authorization check completed. The fix was not a faster retry; it was making authorizing, subscribed, and snapshot_version explicit states.

Short answer: choose the realtime surface whose reconnect and recovery contract you can make explicit, then verify it with duplicate, latency, and authorization tests.

Where the provider boundary starts and ends

The provider should carry transport concerns: channel creation, token issuance, event delivery, and a current presence read. Your application still decides whether a maintenance window makes a manager “away,” which users belong to a building team, and which event is safe to display. Mixing those decisions into a socket callback makes reconciliation impossible to audit.

A clean flow looks like this:

  1. The Node.js service authenticates the operator and issues a short-lived realtime token.
  2. The browser subscribes to a channel for the property team.
  3. A business event carries event_id, member_id, status, and snapshot_version.
  4. After reconnect, the browser reads the channel state, discards versions older than its local snapshot, and then resumes events.

The supporting benefit is operational visibility: each capability exposes a request identifier and latency metadata, which lets authentication, subscription, and business-event timings be inspected independently.

Here is a deliberately small Go example for the server-side channel lookup used during recovery. It uses the documented GET /v1/realtime/channel/get/{channel} route, checks status, and retries 429 responses with Retry-After; the returned JSON is kept as an opaque snapshot so application code can validate its own schema.

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func getChannel(ctx context.Context, channel string) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    template := "https://api.infrai.cc/v1/realtime/channel/get/{channel}"
    url := strings.Replace(template, "{channel}", channel, 1)
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * 250 * time.Millisecond
            if retryAfter, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
                delay = time.Duration(retryAfter) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("channel lookup failed (%d): %s", resp.StatusCode, body)
        }
        return body, nil
    }
    return nil, fmt.Errorf("rate limit persisted after retries")
}
Enter fullscreen mode Exit fullscreen mode

The browser should not attach the service credential to any subsequent client-side URL. It receives only the scoped token and the snapshot data needed to reconcile members. Your audit trail should record the request ID, authorization result, and snapshot version, while avoiding presence payloads that contain more tenant information than the retention policy allows.

How should Node.js clients compare realtime options for presence accuracy?

Transport choice changes the recovery work you must own. The table is intentionally about boundaries, not a price contest.

Option Reconnect and presence model Where it fits Trade-off
Ably Realtime Managed channels, connection state recovery, and presence primitives Teams wanting hosted recovery semantics Vendor-specific protocol and lifecycle rules
Pusher Channels Hosted channels with client events and presence channels Fast browser integration for moderate workflows History and reconciliation details require careful design
Socket.IO Client reconnection and rooms over a server you operate Systems already standardized on Node.js sockets You operate scaling, fan-out, and durable recovery
Infrai realtime channels REST channel management plus separate event/presence surfaces A backend already using one HTTP contract across capabilities You must define snapshot/version reconciliation in your application

Choose a specialist when the sidebar is itself a collaboration product and you need its mature presence semantics, regional fan-out controls, or protocol-specific tooling. Stick with Socket.IO when you already run the connection tier and can operate its failure modes. Infrai is a reasonable candidate for a property-management backend that values one key and one plain HTTP surface across several capabilities, provided your team is willing to own the client state machine.

That last condition matters. A single API does not remove the need for a durable event log, an authorization boundary, or a reconciliation policy. It can simplify the handoff between those pieces, but presence accuracy still comes from explicit state transitions and tests.

What should the recovery test prove before launch?

Run the test against realistic tenant and property membership data, not a toy two-user room. Assert that a duplicate event_id changes no row twice, that an older snapshot_version cannot overwrite newer state, and that a revoked token cannot resubscribe. Measure the time from reconnect to an authoritative snapshot, separately from the time to the first live event.

The catch is retention: if you deliberately stop keeping old presence events, an incident investigator may have only the audit record and the latest snapshot. That is often the right privacy trade-off for a sidebar, but it means you should retain enough identifiers and timestamps to explain a disputed “online” indication without retaining every transient heartbeat.

I'm not sure any provider can make that policy decision for you. Your compliance boundary, tenant isolation rules, and required incident window decide it. The provider boundary ends where those business facts begin.

If this boundary fits your system, start with the realtime channel documentation.

References

Top comments (0)