I’m using @forge/realtime in a Forge app to push live progress from a backend context to a Custom UI frontend. The mechanism works — publishGlobal + signRealtimeToken from a webtrigger reaches a subscribeGlobal listener, verified live.
What I can’t find documented anywhere are the operational limits, and they determine how I design this.
Measured on a dev environment: bursts of 50 and 200 sequential publishGlobal calls — zero failures, zero throttling, ~208ms per call. Couldn’t test 500 in one go, the webtrigger hit the 55s function timeout first (separate limit, not Realtime).
Questions:
-
Is there any limit on publish rate — per second, minute, invocation, or installation? My case would mean a few hundred publishes over a few minutes.
-
If such a limit exists, what happens on breach: explicit error, silently dropped events, throttling?
-
Any limit on the number of distinct channels? I’m considering one channel per operation rather than one global channel filtered client-side. Is per-entity channel naming the intended pattern?
-
Any limit on payload size for a single event?
-
publishGlobal consistently returns {eventId: null, eventTimestamp: null} — no exception — when nothing is subscribed to the channel, and a populated eventId when a subscriber is present. Is this documented somewhere I’ve missed? Can it be relied on, or is it an implementation detail?
Mainly trying to find out whether these limits exist and aren’t published, or whether the service is effectively unbounded in practice.