Realtime

Realtime features keep a WebSocket connection open so the app can send small events quickly. Use it for chat, games, live editors, dashboards, and presence.

`message` is a client-to-server event.
`pubsub` is a server-to-room broadcast.
`room` decides who should receive the event.

Use message

Use `message` for small actions from the browser to the server: read receipt, cursor move, typing status, or game input.

Read receipt

Use pubsub

Use `pubsub` when the server needs to send one event to everyone in a room. A new chat message is the simplest example.

Chat broadcast

Chat Flow

For data that must be saved, write to the database first and publish after the service succeeds.

Save then publish

On the client, subscribe to the room and update local UI state when a new message arrives. Keep the subscription close to the screen that owns the list.

Client subscription

Design Rooms

Use a narrow room key such as `chatId`, `gameId`, or `documentId`.
Avoid one huge room for all users unless everyone truly needs the event.
Use guards so only allowed users can send or subscribe.

Tips

Keep payloads small. Send ids and small patches instead of full pages.
Use `message` for commands and `pubsub` for notifications.
If losing the event is dangerous, save it first and publish after saving.
For games or cursors, throttle very frequent events on the client.

Realtime

Realtime features keep a WebSocket connection open so the app can send small events quickly. Use it for chat, games, live editors, dashboards, and presence.

`message` is a client-to-server event.
`pubsub` is a server-to-room broadcast.
`room` decides who should receive the event.

Use message

Use `message` for small actions from the browser to the server: read receipt, cursor move, typing status, or game input.

Read receipt

Use pubsub

Use `pubsub` when the server needs to send one event to everyone in a room. A new chat message is the simplest example.

Chat broadcast

Chat Flow

For data that must be saved, write to the database first and publish after the service succeeds.

Save then publish

On the client, subscribe to the room and update local UI state when a new message arrives. Keep the subscription close to the screen that owns the list.

Client subscription

Design Rooms

Use a narrow room key such as `chatId`, `gameId`, or `documentId`.
Avoid one huge room for all users unless everyone truly needs the event.
Use guards so only allowed users can send or subscribe.

Tips

Keep payloads small. Send ids and small patches instead of full pages.
Use `message` for commands and `pubsub` for notifications.
If losing the event is dangerous, save it first and publish after saving.
For games or cursors, throttle very frequent events on the client.