Pub/Sub

WebSocket + Dapr realtime messaging

The pubsub block powers realtime: it lets your backend push events to connected clients over WebSocket, and (under Dapr) fan messages out across service instances via a pub/sub component. It's what drives live notifications, presence and any streaming UI.

Reliability features are built in — an ACK system retries unacknowledged messages, presence broadcasting announces who's online, and a cleanup loop reaps stale connections so resources don't leak.

Core#

The connection surface and limits. Defaults are production-ready; override paths only to avoid collisions.

enabledbooleanOptional

Master switch for the pub/sub subsystem.

Defaultfalse

basePathstringOptional

Base path for Dapr subscription endpoints (the routes Dapr posts delivered messages to).

Default"/subs"

wsPathstringOptional

The WebSocket endpoint clients connect to for the realtime feed.

Default"/api/events/subscribe"

pubsubNamestringOptional

Name of the Dapr pub/sub component used to publish and subscribe across instances.

Default"pubsub-redis"

maxClientsPerUsernumberOptional

Cap on simultaneous WebSocket connections per user — prevents a single account exhausting sockets.

Default10

wsIdleTimeoutnumberOptional

Seconds of inactivity before an idle WebSocket is closed. Tune against any proxy idle timeouts in front of the service.

Default120

Acknowledgement (delivery guarantees)#

For messages that matter, the ACK system holds a pending message until the client confirms receipt, retrying on a schedule and giving up after a bounded number of attempts.

ackobjectOptional

At-least-once delivery configuration.

enabledbooleanOptional

Turn on acknowledgement tracking.

ttlSecondsnumberOptional

How long a pending (unacked) message is retained before expiry.

Default300

maxRetriesnumberOptional

Retry attempts before the message is dropped.

Default3

retryIntervalMsnumberOptional

Milliseconds between redelivery attempts.

Default5000

Presence & cleanup#

Presence broadcasts online/offline transitions to interested clients; the cleanup loop removes stale connection records so memory and counts stay accurate.

presence{ enabled?: boolean; debounceMs?: number }Optional

Broadcast user presence. debounceMs (default 5000) coalesces rapid connect/disconnect flaps into a single update.

cleanupIntervalMsnumberOptional

How often stale client records are swept (default every 60s).

Default60000

Under the hood — two transports#

Pub/sub spans two worlds: the WebSocket server your browser clients connect to, and a Dapr publish client for service-to-service messaging. The same logical topics flow through both.

WebSocket serverbrowser clientsOptional

Clients connect at wsPath and subscribe to topics; the server applies the ack and presence behaviour from the config above (acknowledged delivery, presence broadcasts, heartbeats). This is what the usePubSub hook on the Realtime page talks to.

DaprPubSubClientservice-to-serviceOptional

For cross-service messaging the Dapr transport exposes publish(topic, data) and publishBulk(topic, messages[]) against a named pubsub component, with per-message metadata and content type — so one service can emit an event that another consumes via its Dapr subscription.

bulk publishBulkPublishResponseOptional

publishBulk sends many messages in one request and returns failedEntries (entryId + error) for any that didn't make it, so a partial failure is observable rather than silent.

Related sections

Redis Notification Live Monitoring