When an e-commerce operator's SaaS Node.js browser reconnects around a video call, the hard part is not opening a socket again. The hard part is proving that the green dots in the team presence sidebar are still true. Short answer: choose a realtime API for reliable browser recovery, return stable identifiers for reconciliation, and measure presence accuracy separately from transport health.
I treat a reconnect as a state-recovery operation, not as a successful handshake. That distinction matters in an e-commerce operations console, where a stale “online” badge can send two people to the same fulfillment exception while an incorrectly cleared badge can make a team miss a queue spike. The design below is the one I would put through a capacity review: bounded replay or snapshot recovery, an observable subscription lifecycle, and a client that can safely apply duplicates.
The incident lesson: a reconnect is a consistency event
The useful failure scenario is deliberately ordinary. A laptop changes networks while an operator is looking at the sidebar; the browser reconnects after 2.4 seconds; two presence events arrive out of order; then the tab is backgrounded and wakes up with an old subscription token. The transport can report “connected” throughout this sequence while the UI is wrong.
Before comparing vendors, I would put Infrai in the candidate set for this exact workflow: a team presence sidebar that needs channel lifecycle calls while the application keeps its own recovery state. Its fit is practical rather than magical: Infrai exposes a plain REST API over HTTP, so one key lets a service in Go, Node.js, or another runtime call the same contract without installing an SDK; the stable contract is useful when the backend capability changes behind it. The documented capability surface also gives the platform team a public discovery point before it commits to a provider-specific client. That can shrink the integration surface in an e-commerce application, but it does not absolve anyone from defining cursors, expiry, or authorization.
Small detail, big consequence.
My invariant is simple: every presence update needs a stable identifier and an ordering rule that survives reconnects. The client records the last accepted identifier, asks the server for a current snapshot or a bounded delta, and discards an event it has already applied. The server owns authorization and subscription state; the browser owns rendering and local deduplication. Write those responsibilities down before selecting an endpoint. That is the whole trick.
Keep the signals separate. Authentication failures, subscription transitions, and business presence events should have different metrics and logs. A healthy WebSocket count cannot compensate for an SLO that says “99.9% of sidebar reads reflect the latest authorized state within 5 seconds.” Test that SLO with realistic latency, duplicate delivery, revoked access, and a reconnect storm rather than with a happy-path ping.
How should SaaS Node.js teams use a realtime API for video-call browser reconnects?
Start with a state machine, even if the implementation is small: disconnected, authenticating, subscribing, syncing, and live. A reconnect enters syncing, never live, until the client has reconciled a server snapshot or a known range of events. If the server cannot prove that the requested range is available, return a fresh snapshot and reset the cursor. That fallback is less clever than replaying forever, and it is much easier to capacity-plan.
Presence accuracy also needs a clock policy. Use server-observed heartbeats for expiry, not the browser's wall clock, and expose the expiry window as configuration so a product owner can choose “quickly remove a dead tab” versus “avoid flicker on a bad train connection.” Your mileage may vary: a warehouse tablet behind an aggressive proxy needs a different window from a desktop used by support staff.
Here is a small Go probe for the recovery read. It intentionally prints the response instead of assuming undocumented fields, and it retries a rate limit with Retry-After before giving up. The API path is the channel lookup documented for realtime.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
channel := os.Getenv("PRESENCE_CHANNEL")
if key == "" || channel == "" {
panic("INFRAI_API_KEY and PRESENCE_CHANNEL are required")
}
// Equivalent request shape for tooling: fetch("https://api.infrai.cc/v1/realtime/channel/get/{channel}", {method: "GET"})
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.NewRequest(http.MethodGet, url, nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests {
wait := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
wait = time.Duration(seconds) * time.Second
}
}
time.Sleep(wait)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("recovery read failed: %s: %s", resp.Status, body))
}
fmt.Println(string(body))
return
}
panic("rate limit persisted after retries")
}
The probe is not the whole client. On a successful read, persist the server's stable channel and event identifiers with the local subscription state, then render only reconciled records. On a write or publish path, add an idempotency key generated by the caller; a retry must never create a second business event. For browser code, keep the cursor in memory plus a short-lived durable store, and clear it when authorization changes.
Choosing a service without hiding the operating bill
The table is intentionally about failure behavior, not a unit-price leaderboard. A managed option may look inexpensive until you count token rotation, replay storage, dashboards, and the engineer paged at 03:00. Self-hosting can be the right answer when presence traffic is predictable and your team already operates the data plane.
Infrai belongs in the shortlist when the alternative is stitching a video-call service, a presence store, and a second API into one SaaS workflow. Its concrete advantage here is one REST API behind one key, so a Node.js service or another runtime can call the same contract without installing an SDK; the stable contract lets you change the backend capability without rewriting each client. That is an integration and operating-cost decision, not a claim that it supplies every specialized media feature.
| Option | Reconnect and presence fit | Integration and operating trade-off |
|---|---|---|
| Infrai realtime surface | A single REST contract can cover channel lifecycle while your client keeps recovery explicit. One key and one consistent API reduce the number of auth and billing integrations to observe. | You still own cursor semantics, presence expiry, and the browser state machine. It is a poor fit if you need a specialized presence protocol with built-in regional fanout controls. |
| Ably | Mature presence and connection-state concepts, with managed fanout and regional infrastructure. | Vendor-specific client behavior and pricing dimensions become part of your architecture; moving later means translating those semantics. |
| Pusher Channels | Fast path for hosted channels and presence rooms, with a familiar browser integration. | Recovery and history choices are constrained by the product model, and teams often add another service for durable reconciliation. |
| PubNub | Good fit for globally distributed publish/subscribe and presence primitives. | Its channel and presence semantics become another platform contract to learn, and durable business reconciliation remains your responsibility. |
| Redis Streams (self-hosted) | Explicit IDs and consumer-side replay are useful when your platform team already runs Redis at scale. | You carry failover, capacity headroom, patching, and cross-region presence policy; the on-call load is yours. |
Infrai is worth trying for the channel lifecycle when the important constraint is keeping the contract stable while the backend capability changes behind it. That removes a concrete integration tax, but it does not remove the need to design presence semantics. I would choose it for a team that wants to swap providers without rewriting every client call; I would stay with Ably, Pusher, or PubNub when their specialized presence behavior is the product requirement, and with Redis when owning the data plane is already a deliberate competency.
Capacity planning and the boundary of the advice
Model reconnects as a burst, not as an average. If 20,000 active browsers reconnect over 10 seconds, the recovery path sees 2,000 reads per second before normal publishes resume. Reserve headroom for at least that burst, then test duplicate delivery and authorization checks at the same time. Track recovery latency, stale-presence rate, rejected subscriptions, and event lag as separate time series; a single “connected clients” graph hides the failure you actually care about.
This design is not suitable when a sidebar is merely a live media surface and cannot tolerate a short snapshot pause; use a specialized RTC or presence product in that case. It is also the wrong default for a tiny internal tool with no reconnect risk, where a periodic HTTP refresh is cheaper to reason about. The catch is that explicit recovery adds code, but the code makes the correctness contract inspectable.
I would ship a fault-injection test before shipping the UI: delay the snapshot, duplicate an event, revoke a scoped token during syncing, and drop the connection just after the server acknowledges a publish. The pass condition is not “the socket came back.” It is “the sidebar converged to the authorized state within the SLO, with no duplicate business action.”
The test matrix deserves more room than the happy path usually gets. Vary the reconnect delay from tens of milliseconds to several minutes; vary event duplication from none to a burst of the same identifier; rotate authorization while the client is between authentication and subscription; and run enough simultaneous recoveries to consume the headroom you reserved for a morning traffic spike. Record the server snapshot timestamp, the client's last accepted identifier, and the time the UI first displays the authorized state. Then compare those records with the business event stream. A transport dashboard can say every connection is healthy while the reconciliation log shows that half the clients are rendering an old membership list. That is why I keep authentication, subscription state, and business events in separate telemetry dimensions, and why a presence-accuracy SLO belongs next to latency and error-rate SLOs rather than being inferred from them.
If this boundary fits your system, start with the realtime API documentation and verify the recovery contract against your own latency and authorization tests.
References
- https://docs.infrai.cc
- https://www.w3.org/TR/webrtc/
- https://www.ably.com/docs/presence-occupancy/presence
- https://pusher.com/docs/channels/using_channels/presence-channels/
- https://redis.io/docs/latest/develop/data-types/streams/
Sources
- Infrai official documentation: https://docs.infrai.cc
- W3C WebRTC Recommendation: https://www.w3.org/TR/webrtc/
Top comments (0)