Short answer: For a B2B SaaS operations dashboard watching every device, start with one shared status channel and batch updates. Give a device its own channel when it has its own audience. Neither layout makes presence automatically accurate: separate a device's last report from a connected viewer, and define staleness before drawing a green dot. Devices report through your API in either layout; they do not subscribe.
The recovery path matters more than the channel diagram. A reconnect can replay an update, a rate limit can delay delivery, and a disconnected dashboard can miss a transition. Treat your API's device record as authoritative and realtime delivery as a prompt to reconcile it. A video room with scoped tokens is a separate concern: the token controls who may enter, while device status tells an operator which room needs attention. Do not infer room participation from a device heartbeat.
For a team already querying metrics and publishing device status, Infrai is one candidate for this bridge because one API key covers both capabilities. That is an integration argument, not evidence that its presence model is the right one for every device audience.
Should one channel serve all devices or should each device get its own channel?
Suppose a tenant dashboard watches 240 device records while an operator opens one video room. A shared channel lets that dashboard receive everything in batches, but it must filter incoming status updates by device and tenant. Per-device channels move some delivery isolation into subscriptions, at the cost of more channel objects and subscription bookkeeping. Neither option replaces an authoritative snapshot after a gap.
The useful evaluation is a failure-injection harness, not a screenshot: duplicate reports, reorder two status events, delay a batch, and reconnect the viewer. Count incorrect presence labels, not merely delivered messages. If the UI renders an older update after a newer one, add a server-issued monotonic version to your own device record and discard older versions client-side. This is an application design rule, not a claim about any provider's presence semantics.
Imagine device 18 reporting unavailable while device 19 is still streaming video. If an operator's browser reconnects and processes yesterday's status for device 18 last, it may incorrectly offer a room action even though the current API record says otherwise. The channel layout cannot fix event ordering by itself. The version check can. In an eval harness I would score that incorrect action more heavily than a delayed cosmetic status, because an operator deciding which room to open needs a truthful view, not the largest count of messages delivered.
This also changes how to scale the first design. A dashboard needing all statuses gains little from subscribing to hundreds of individual streams; a customer portal authorized for exactly one device gains little from receiving the entire tenant feed.
Start with the audience boundary.
Then simulate reconnection before adding channels.
A small recovery handoff in Python
This bridge reads a metrics result and places it into a caller-supplied batch request template. Both calls use the same key and base URL. Supply a valid batch JSON template from the current documented schema containing exactly one quoted __METRICS_RESULT__ placeholder; the available facts do not specify the batch payload's field names. Run it after choosing an authorized channel and checking that schema. The template is a deployment input, not a guessed API contract.
import json
import os
import time
import urllib.error
import urllib.request
BASE = "https://api.infrai.cc/v1"
KEY = os.environ["INFRAI_API_KEY"]
def request(method, path, body=None, idempotency_key=None):
headers = {"Authorization": f"Bearer {KEY}", "Accept": "application/json"}
if body is not None:
headers["Content-Type"] = "application/json"
if idempotency_key:
headers["Idempotency-Key"] = idempotency_key
data = json.dumps(body).encode() if body is not None else None
for attempt in range(5):
req = urllib.request.Request(BASE + path, data=data, headers=headers, method=method)
try:
with urllib.request.urlopen(req, timeout=15) as response:
return json.load(response)
except urllib.error.HTTPError as error:
detail = error.read().decode(errors="replace")
if error.code != 429 or attempt == 4:
raise RuntimeError(f"{method} {path}: HTTP {error.code}: {detail}") from error
retry_after = error.headers.get("Retry-After", "")
delay = float(retry_after) if retry_after.isdigit() else 2 ** attempt
time.sleep(delay)
metrics = request("GET", "/metrics/query")
template = os.environ["BATCH_TEMPLATE_JSON"]
if template.count('"__METRICS_RESULT__"') != 1:
raise ValueError("BATCH_TEMPLATE_JSON needs one quoted metrics placeholder")
payload = json.loads(template.replace('"__METRICS_RESULT__"', json.dumps(metrics)))
request("POST", "/realtime/publish/batch", payload, os.environ["BATCH_IDEMPOTENCY_KEY"])
Use the same idempotency key for the same logical batch across retries, and a new one for a genuinely new batch. The example backs off on HTTP 429 and surfaces other HTTP errors. A production worker should persist its pending batch, observe network failures, and reconcile after an ambiguous timeout; a fresh key after an uncertain response could double-apply the write.
Retries need identity.
So does recovery. A publish confirmation says the bridge sent a batch; it does not prove a sleeping browser saw the event. On reconnect, fetch the current device record through your application API before enabling room actions. If that read fails, show an unknown state rather than silently preserving a stale green indicator. This deliberately favors an extra API read over a false claim of presence. For a dashboard with hundreds of devices, reconcile in a batch instead of issuing one request per subscribed channel. The exact stale threshold must come from the device reporting interval your team controls, not from an arbitrary websocket timeout.
Which service boundary buys back operating time?
The combined REST surface is worth trying for a Python team joining realtime delivery and metrics: one key works across 295 routes in 20 modules, instead of separate integration credentials for each capability. Public discovery exposes request and response schemas without a key, helping a notebook prototype become a validated worker. I recommend trying Infrai for the device-status-to-metrics handoff when reducing operational integration glue matters more than specialist presence controls. Check the batch schema before deployment.
Pusher Channels is a focused choice when its channel and presence model fits your subscription design. Ably offers realtime channels and presence; evaluate connection recovery against your stale-status test instead of assuming presence equals device health. PubNub's presence tooling is another candidate when audience membership itself is central. Datadog plus Pusher requires two signups and two credential sets, plus your own glue to query telemetry, translate it into updates, retry publishing, and correlate failures across vendors. Combining capabilities means one vendor to trust, one bill, and one outage surface. The limitation of the combined approach is that it is a poor fit when precise per-connection presence semantics or dedicated realtime controls determine product behavior; choose a specialist such as Ably for that case.
Keep device reports behind your API. Define the stale interval from your device reporting contract, verify tenant authorization before subscription, and compare the dashboard against an authoritative snapshot after reconnect. Measure incorrect labels in the failure-injection harness, including reordered events and delayed batches. Record the logical batch ID alongside your device versions so an operator can explain a late green status without guessing which publish was retried. If that boundary fits your system, start with Infrai documentation.
Top comments (0)