chat-room

Name: chat-room
Author: rivet-dev

680installs7forks

How to install chat-room?

rivet-dev/skills/chat-room

$npx -y skills add rivet-dev/skills --skill chat-room

Installs into the current project.

Summary

Build a realtime chat room backend with Rivet Actors: one actor per room, SQLite-backed message history, and WebSocket broadcast to every connected client.

Files · 1

View on GitHub

SKILL.md

1	# Chat Room
2
3	IMPORTANT: Before doing anything, you MUST read `BASE_SKILL.md` in this skill's directory. It contains essential guidance on debugging, error handling, state management, deployment, and project setup. Those rules and patterns apply to all RivetKit work. Everything below assumes you have already read and understood it.
4
5	## Working Examples
6
7	If you need a reference implementation, read the raw working example code in these templates:
8
9	- [chat-room](https://github.com/rivet-dev/rivet/tree/main/examples/chat-room)
10
11
12	Patterns for building a chat room backend with RivetKit: room-scoped actors, persistent message history, and realtime delivery over WebSocket connections.
13
14	## Starter Code
15
16	Start with the working example on [GitHub](https://github.com/rivet-dev/rivet/tree/main/examples/chat-room) and adapt it. The backend is a single `chatRoom` actor; the frontend is a React app using `@rivetkit/react` (see the [React quickstart](/docs/actors/quickstart/react)).
17
18	\| Topic \| Summary \|
19	\| --- \| --- \|
20	\| Room model \| One `chatRoom` actor per room key. The frontend defaults the key to `general`; typing a different room name connects to a different actor. \|
21	\| History \| SQLite `messages` table created in `db({ onMigrate })`, read back with `ORDER BY id ASC`. \|
22	\| Delivery \| `sendMessage` inserts the row, then broadcasts a typed `newMessage` event to every connected client. \|
23	\| Identity \| None in the example. `sender` is a plain action argument; production should bind identity to the connection. \|
24
25	## Room-Per-Actor Model
26
27	Each room is one Rivet Actor instance, addressed by [key](/docs/actors/keys). The client calls `useActor({ name: "chatRoom", key: [roomId] })`, which gets-or-creates the actor for that room. This gives you:
28
29	- Isolation: each room's history and connections are fully scoped to its key. Switching the room input re-keys the hook and connects to a different actor with separate history.
30	- A single serialized writer: all `sendMessage` calls for one room run through one actor, so message ordering is consistent without locks. The SQLite `AUTOINCREMENT` id is the canonical order, which is why `getHistory` sorts by `id` rather than by timestamp.
31	- Natural scaling: rooms spread across the cluster independently. A hot room does not slow down other rooms.
32
33	## Message History Storage
34
35	This example stores history in the actor's SQLite database, not in JSON state. Pick based on history size and query needs:
36
37	\| Approach \| Use When \| Implementation Guidance \|
38	\| --- \| --- \| --- \|
39	\| [SQLite](/docs/actors/sqlite) (what this example uses) \| Large or long-lived history that needs ordering, caps, pagination, or search \| Create the `messages` table in `db({ onMigrate })`, insert with parameterized queries (`c.db.execute("INSERT ... VALUES (?, ?, ?)", ...)`), and read with `ORDER BY id ASC`. History survives actor sleep and scales past what you want in memory. \|
40	\| [JSON state](/docs/actors/state) \| Small recent history, for example the last 50 to 100 messages \| Push onto a `messages` array in actor state and trim to a cap on every send. Simplest option, but the whole history lives in memory and there is no query layer, so it only fits bounded recent-history use cases. \|
41
42	## Broadcast Delivery
43
44	New messages reach connected clients through a typed [event](/docs/actors/events):
45
46	- The actor declares `events: { newMessage: event() }`, where `Message` is `{ sender, text, timestamp }`.
47	- The `sendMessage` [action](/docs/actors/actions) builds the message with a server-side `Date.now()` timestamp, inserts it into the `messages` table, then calls `c.broadcast("newMessage", message)` and returns the message to the caller.
48	- Each client subscribes with `useEvent("newMessage", ...)` and appends to its local list. The sender renders its own message through the same broadcast path as everyone else, so all clients stay on one code path.
49	- History load is connection-gated: once the connection is ready, the client calls `getHistory()` once to render the backlog, then relies on events for everything after.
50
51	Use `c.broadcast(...)` for room-wide messages. For private or per-recipient payloads (such as DMs inside a room), send on the individual connection instead, which is a recommended extension beyond this example.
52
53	## Typing Indicators And Presence (Extension)
54
55	The example does not implement typing indicators, presence, or join/leave handling of any kind. There is no `createConnState`, `onConnect`, or `onDisconnect` in the code. If you need them, add them as ephemeral [connection](/docs/actors/connections) behavior:
56
57	- Keep it ephemeral: store the username and typing flag in per-connection state, never in SQLite or persisted actor state. Presence is derived from live connections and should disappear with them.
58	- **Broadcast

People who liked this also viewed

6 picks

Type

chat-room

680installs7forks

View on GitHub

How to install chat-room?

rivet-dev/skills/chat-room

$npx -y skills add rivet-dev/skills --skill chat-room

Installs into the current project.

Summary

Build a realtime chat room backend with Rivet Actors: one actor per room, SQLite-backed message history, and WebSocket broadcast to every connected client.

Files · 1

View on GitHub

SKILL.md

1	# Chat Room
2
3	IMPORTANT: Before doing anything, you MUST read `BASE_SKILL.md` in this skill's directory. It contains essential guidance on debugging, error handling, state management, deployment, and project setup. Those rules and patterns apply to all RivetKit work. Everything below assumes you have already read and understood it.
4
5	## Working Examples
6
7	If you need a reference implementation, read the raw working example code in these templates:
8
9	- [chat-room](https://github.com/rivet-dev/rivet/tree/main/examples/chat-room)
10
11
12	Patterns for building a chat room backend with RivetKit: room-scoped actors, persistent message history, and realtime delivery over WebSocket connections.
13
14	## Starter Code
15
16	Start with the working example on [GitHub](https://github.com/rivet-dev/rivet/tree/main/examples/chat-room) and adapt it. The backend is a single `chatRoom` actor; the frontend is a React app using `@rivetkit/react` (see the [React quickstart](/docs/actors/quickstart/react)).
17
18	\| Topic \| Summary \|
19	\| --- \| --- \|
20	\| Room model \| One `chatRoom` actor per room key. The frontend defaults the key to `general`; typing a different room name connects to a different actor. \|
21	\| History \| SQLite `messages` table created in `db({ onMigrate })`, read back with `ORDER BY id ASC`. \|
22	\| Delivery \| `sendMessage` inserts the row, then broadcasts a typed `newMessage` event to every connected client. \|
23	\| Identity \| None in the example. `sender` is a plain action argument; production should bind identity to the connection. \|
24
25	## Room-Per-Actor Model
26
27	Each room is one Rivet Actor instance, addressed by [key](/docs/actors/keys). The client calls `useActor({ name: "chatRoom", key: [roomId] })`, which gets-or-creates the actor for that room. This gives you:
28
29	- Isolation: each room's history and connections are fully scoped to its key. Switching the room input re-keys the hook and connects to a different actor with separate history.
30	- A single serialized writer: all `sendMessage` calls for one room run through one actor, so message ordering is consistent without locks. The SQLite `AUTOINCREMENT` id is the canonical order, which is why `getHistory` sorts by `id` rather than by timestamp.
31	- Natural scaling: rooms spread across the cluster independently. A hot room does not slow down other rooms.
32
33	## Message History Storage
34
35	This example stores history in the actor's SQLite database, not in JSON state. Pick based on history size and query needs:
36
37	\| Approach \| Use When \| Implementation Guidance \|
38	\| --- \| --- \| --- \|
39	\| [SQLite](/docs/actors/sqlite) (what this example uses) \| Large or long-lived history that needs ordering, caps, pagination, or search \| Create the `messages` table in `db({ onMigrate })`, insert with parameterized queries (`c.db.execute("INSERT ... VALUES (?, ?, ?)", ...)`), and read with `ORDER BY id ASC`. History survives actor sleep and scales past what you want in memory. \|
40	\| [JSON state](/docs/actors/state) \| Small recent history, for example the last 50 to 100 messages \| Push onto a `messages` array in actor state and trim to a cap on every send. Simplest option, but the whole history lives in memory and there is no query layer, so it only fits bounded recent-history use cases. \|
41
42	## Broadcast Delivery
43
44	New messages reach connected clients through a typed [event](/docs/actors/events):
45
46	- The actor declares `events: { newMessage: event() }`, where `Message` is `{ sender, text, timestamp }`.
47	- The `sendMessage` [action](/docs/actors/actions) builds the message with a server-side `Date.now()` timestamp, inserts it into the `messages` table, then calls `c.broadcast("newMessage", message)` and returns the message to the caller.
48	- Each client subscribes with `useEvent("newMessage", ...)` and appends to its local list. The sender renders its own message through the same broadcast path as everyone else, so all clients stay on one code path.
49	- History load is connection-gated: once the connection is ready, the client calls `getHistory()` once to render the backlog, then relies on events for everything after.
50
51	Use `c.broadcast(...)` for room-wide messages. For private or per-recipient payloads (such as DMs inside a room), send on the individual connection instead, which is a recommended extension beyond this example.
52
53	## Typing Indicators And Presence (Extension)
54
55	The example does not implement typing indicators, presence, or join/leave handling of any kind. There is no `createConnState`, `onConnect`, or `onDisconnect` in the code. If you need them, add them as ephemeral [connection](/docs/actors/connections) behavior:
56
57	- Keep it ephemeral: store the username and typing flag in per-connection state, never in SQLite or persisted actor state. Presence is derived from live connections and should disappear with them.
58	- **Broadcast

People who liked this also viewed

6 picks

Type