@jskit-ai/agent-docs 0.1.3 → 0.1.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/DISTR_AGENT.md +11 -1
- package/guide/agent/app-extras/assistant.md +1 -1
- package/guide/agent/app-extras/realtime.md +1 -1
- package/guide/agent/app-setup/a-more-interesting-shell.md +1 -1
- package/guide/agent/app-setup/authentication.md +9 -1
- package/guide/agent/app-setup/console.md +1 -1
- package/guide/agent/app-setup/database-layer.md +1 -1
- package/guide/agent/app-setup/initial-scaffolding.md +1 -1
- package/guide/agent/app-setup/multi-homing.md +3 -1
- package/guide/agent/app-setup/users.md +1 -1
- package/guide/agent/app-setup/working-with-the-jskit-cli.md +1 -1
- package/guide/agent/generators/advanced-cruds.md +163 -1
- package/guide/agent/generators/crud-generators.md +30 -1
- package/guide/agent/generators/intro.md +1 -1
- package/guide/agent/generators/ui-generators.md +1 -1
- package/guide/agent/index.md +1 -1
- package/package.json +1 -1
- package/reference/autogen/packages/agent-docs.md +18 -0
- package/skills/jskit-review/SKILL.md +12 -2
- package/templates/APP_BLUEPRINT.md +9 -0
- package/templates/WORKBOARD.md +3 -3
- package/templates/app/AGENTS.md +15 -3
- package/workflow/bootstrap.md +17 -2
- package/workflow/feature-delivery.md +19 -3
- package/workflow/review.md +9 -3
- package/workflow/scoping.md +10 -1
- package/workflow/workboard.md +1 -1
- package/guide/human/app-extras/assistant.md +0 -693
- package/guide/human/app-extras/realtime.md +0 -268
- package/guide/human/app-setup/a-more-interesting-shell.md +0 -732
- package/guide/human/app-setup/authentication.md +0 -961
- package/guide/human/app-setup/console.md +0 -350
- package/guide/human/app-setup/database-layer.md +0 -820
- package/guide/human/app-setup/initial-scaffolding.md +0 -753
- package/guide/human/app-setup/multi-homing.md +0 -793
- package/guide/human/app-setup/users.md +0 -402
- package/guide/human/app-setup/working-with-the-jskit-cli.md +0 -1047
- package/guide/human/generators/advanced-cruds.md +0 -921
- package/guide/human/generators/crud-generators.md +0 -554
- package/guide/human/generators/intro.md +0 -107
- package/guide/human/generators/ui-generators.md +0 -663
- package/guide/human/index.md +0 -37
|
@@ -1,268 +0,0 @@
|
|
|
1
|
-
# Realtime
|
|
2
|
-
|
|
3
|
-
At the end of the previous chapter, the app already had a real shell, authenticated users, operator tooling, and workspace-aware routing. What it still did not have was a live transport for pushing updates into that shell.
|
|
4
|
-
|
|
5
|
-
This chapter installs `realtime`, which adds JSKIT's socket.io runtime, Vite websocket proxy wiring, and a small connection indicator in the shell.
|
|
6
|
-
|
|
7
|
-
This package is a good example of an "extra" rather than a new structural layer. It does not create new surfaces and it does not generate new pages. Instead, it plugs live behavior into things the guide has already scaffolded.
|
|
8
|
-
|
|
9
|
-
## Recap from previous chapters
|
|
10
|
-
|
|
11
|
-
To get back to the same starting point as the end of the previous chapter, run:
|
|
12
|
-
|
|
13
|
-
```bash
|
|
14
|
-
SUPABASE_URL=...
|
|
15
|
-
SUPABASE_KEY=...
|
|
16
|
-
DB_HOST=127.0.0.1
|
|
17
|
-
DB_PORT=3306
|
|
18
|
-
DB_NAME=exampleapp
|
|
19
|
-
DB_USER=exampleapp
|
|
20
|
-
DB_PASSWORD=secret
|
|
21
|
-
|
|
22
|
-
npx @jskit-ai/create-app exampleapp --tenancy-mode personal
|
|
23
|
-
cd exampleapp
|
|
24
|
-
npm install
|
|
25
|
-
|
|
26
|
-
npx jskit add package shell-web
|
|
27
|
-
npx jskit add package auth-provider-supabase-core \
|
|
28
|
-
--auth-supabase-url "$SUPABASE_URL" \
|
|
29
|
-
--auth-supabase-publishable-key "$SUPABASE_KEY" \
|
|
30
|
-
--app-public-url "http://localhost:5173"
|
|
31
|
-
npx jskit add bundle auth-base
|
|
32
|
-
npx jskit add package database-runtime-mysql \
|
|
33
|
-
--db-host "$DB_HOST" \
|
|
34
|
-
--db-port "$DB_PORT" \
|
|
35
|
-
--db-name "$DB_NAME" \
|
|
36
|
-
--db-user "$DB_USER" \
|
|
37
|
-
--db-password "$DB_PASSWORD"
|
|
38
|
-
npx jskit add package users-web
|
|
39
|
-
npx jskit add package console-web
|
|
40
|
-
npx jskit add package workspaces-core
|
|
41
|
-
npx jskit add package workspaces-web
|
|
42
|
-
npm install
|
|
43
|
-
npm run db:migrate
|
|
44
|
-
```
|
|
45
|
-
|
|
46
|
-
If you are already continuing from the previous chapter, you are already in the right place and can skip that setup.
|
|
47
|
-
|
|
48
|
-
<DocsTerminalTip label="Redis" title="Empty Is Fine Locally">
|
|
49
|
-
`realtime` writes `REALTIME_REDIS_URL` into `.env`, but leaving it empty is a perfectly normal local setup.
|
|
50
|
-
|
|
51
|
-
With no Redis URL, the package uses the in-memory socket adapter inside your single local Node process. That is enough for local development and for small single-instance deployments.
|
|
52
|
-
|
|
53
|
-
You only need to set `REALTIME_REDIS_URL` when you want several server instances to share socket events through Redis.
|
|
54
|
-
</DocsTerminalTip>
|
|
55
|
-
|
|
56
|
-
## Installing `realtime`
|
|
57
|
-
|
|
58
|
-
From inside `exampleapp`, run:
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
npx jskit add package realtime
|
|
62
|
-
npm install
|
|
63
|
-
```
|
|
64
|
-
|
|
65
|
-
The first command records the runtime package in the app and updates the existing scaffold. The second command downloads the new dependencies, especially `socket.io`, `socket.io-client`, and the optional Redis adapter pieces.
|
|
66
|
-
|
|
67
|
-
Unlike the database, users, console, and workspace chapters, this one does **not** need `npm run db:migrate`. `realtime` does not add schema files. It is transport infrastructure, not persistence.
|
|
68
|
-
|
|
69
|
-
## What changes now
|
|
70
|
-
|
|
71
|
-
Installing `realtime` changes the app in three important ways.
|
|
72
|
-
|
|
73
|
-
### The app gets a realtime transport
|
|
74
|
-
|
|
75
|
-
The server now mounts a socket.io runtime on the same Fastify server that already serves your JSKIT surfaces. The browser gets a matching socket.io client runtime through the normal client boot process.
|
|
76
|
-
|
|
77
|
-
That means later modules, or your own app code, can stop thinking only in terms of request/response HTTP flows. They can start publishing live events and listening for them in Vue.
|
|
78
|
-
|
|
79
|
-
### The shell gets a connection indicator
|
|
80
|
-
|
|
81
|
-
The package also uses the shell scaffolding that already exists.
|
|
82
|
-
|
|
83
|
-
`realtime` appends a placement entry into `src/placement.js` that targets `shell-layout:top-right`, so the shell starts showing a small status dot without you having to create a new page for it.
|
|
84
|
-
|
|
85
|
-
That dot is:
|
|
86
|
-
|
|
87
|
-
- green when the realtime socket is connected
|
|
88
|
-
- red when the socket is disconnected or still reconnecting
|
|
89
|
-
|
|
90
|
-
So the first visible value of the package is not a whole new screen. It is a tiny live status element plugged straight into the existing shell.
|
|
91
|
-
|
|
92
|
-
### Vite starts proxying websocket traffic too
|
|
93
|
-
|
|
94
|
-
The app already had a browser dev server on `5173` and a backend runtime on `3000`.
|
|
95
|
-
|
|
96
|
-
`realtime` extends that setup by writing a websocket proxy entry into `.jskit/vite.dev.proxy.json` for `/socket.io`. That matters because the browser should still talk to the frontend dev server on `5173`, while Vite quietly forwards websocket traffic to the backend runtime on `3000`.
|
|
97
|
-
|
|
98
|
-
So one of the main values of this package is that you do **not** have to hand-edit Vite config just to make socket.io work in local development.
|
|
99
|
-
|
|
100
|
-
### There are still no new pages
|
|
101
|
-
|
|
102
|
-
This is worth saying clearly because it can otherwise feel surprising.
|
|
103
|
-
|
|
104
|
-
After installing `realtime`:
|
|
105
|
-
|
|
106
|
-
- there is still no `/realtime` page
|
|
107
|
-
- there is still no new surface
|
|
108
|
-
- there is still no app-owned `src/pages/...` scaffold
|
|
109
|
-
|
|
110
|
-
That is intentional. `realtime` is infrastructure. It makes the existing shell and later runtime packages live-capable instead of giving the app a new section of its own.
|
|
111
|
-
|
|
112
|
-
## What to look at in the browser
|
|
113
|
-
|
|
114
|
-
Start both processes again:
|
|
115
|
-
|
|
116
|
-
```bash
|
|
117
|
-
npm run dev
|
|
118
|
-
npm run server
|
|
119
|
-
```
|
|
120
|
-
|
|
121
|
-
Then open `http://localhost:5173/home`.
|
|
122
|
-
|
|
123
|
-
The important visible change is in the top-right of the shell. You should now see the realtime status dot alongside the other shell controls.
|
|
124
|
-
|
|
125
|
-
If the websocket connects successfully, the dot is green. If the backend is unavailable or the socket is reconnecting, the dot is red. Hovering it shows the current status text.
|
|
126
|
-
|
|
127
|
-
That small change is the whole point of this chapter's browser check: the package is already active even though it did not create a page of its own.
|
|
128
|
-
|
|
129
|
-
## Using the client runtime
|
|
130
|
-
|
|
131
|
-
The connection indicator is useful, but the real reason to install `realtime` is to let client code subscribe to live events.
|
|
132
|
-
|
|
133
|
-
The smallest client-side example looks like this:
|
|
134
|
-
|
|
135
|
-
```vue
|
|
136
|
-
<script setup>
|
|
137
|
-
import { ref } from "vue";
|
|
138
|
-
import { useRealtimeEvent } from "@jskit-ai/realtime/client/composables/useRealtimeEvent";
|
|
139
|
-
|
|
140
|
-
const lastEvent = ref("Nothing received yet.");
|
|
141
|
-
|
|
142
|
-
useRealtimeEvent({
|
|
143
|
-
event: "demo.ping",
|
|
144
|
-
onEvent({ payload }) {
|
|
145
|
-
lastEvent.value = JSON.stringify(payload);
|
|
146
|
-
}
|
|
147
|
-
});
|
|
148
|
-
</script>
|
|
149
|
-
|
|
150
|
-
<template>
|
|
151
|
-
<p>{{ lastEvent }}</p>
|
|
152
|
-
</template>
|
|
153
|
-
```
|
|
154
|
-
|
|
155
|
-
That composable does not create any server-side events by itself. It only subscribes the component to the client socket.
|
|
156
|
-
|
|
157
|
-
The important pieces are:
|
|
158
|
-
|
|
159
|
-
- `event`
|
|
160
|
-
- the event name to listen for
|
|
161
|
-
- if you omit it, the composable listens to `*`
|
|
162
|
-
- `onEvent`
|
|
163
|
-
- the handler that receives `{ event, payload, socket }`
|
|
164
|
-
- `matches`
|
|
165
|
-
- an optional predicate if you want to filter events before the handler runs
|
|
166
|
-
|
|
167
|
-
So the mental model is:
|
|
168
|
-
|
|
169
|
-
- `realtime` gives the app a live transport
|
|
170
|
-
- your own app code, or later packages, decide which events should travel across it
|
|
171
|
-
|
|
172
|
-
## What `realtime` adds to the app
|
|
173
|
-
|
|
174
|
-
This chapter is small enough that it is worth looking directly at the app-owned files it changes.
|
|
175
|
-
|
|
176
|
-
### `.env` gains the Redis adapter setting
|
|
177
|
-
|
|
178
|
-
The install writes:
|
|
179
|
-
|
|
180
|
-
```dotenv
|
|
181
|
-
REALTIME_REDIS_URL=
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
That empty value is deliberate. It means the app can start with the in-memory adapter locally, and you can fill in a real Redis URL later if you need cross-instance fan-out.
|
|
185
|
-
|
|
186
|
-
### `.jskit/vite.dev.proxy.json` gains a websocket proxy entry
|
|
187
|
-
|
|
188
|
-
After the install, the app has:
|
|
189
|
-
|
|
190
|
-
```json
|
|
191
|
-
{
|
|
192
|
-
"version": 1,
|
|
193
|
-
"entries": [
|
|
194
|
-
{
|
|
195
|
-
"packageId": "@jskit-ai/realtime",
|
|
196
|
-
"id": "realtime-socket-io",
|
|
197
|
-
"path": "/socket.io",
|
|
198
|
-
"changeOrigin": true,
|
|
199
|
-
"ws": true
|
|
200
|
-
}
|
|
201
|
-
]
|
|
202
|
-
}
|
|
203
|
-
```
|
|
204
|
-
|
|
205
|
-
That one entry is what lets the browser dev server proxy websocket traffic correctly during local development.
|
|
206
|
-
|
|
207
|
-
### `src/placement.js` grows one new shell placement
|
|
208
|
-
|
|
209
|
-
The package appends this placement:
|
|
210
|
-
|
|
211
|
-
```js
|
|
212
|
-
addPlacement({
|
|
213
|
-
id: "realtime.connection.indicator",
|
|
214
|
-
target: "shell-layout:top-right",
|
|
215
|
-
surfaces: ["*"],
|
|
216
|
-
order: 950,
|
|
217
|
-
componentToken: "realtime.web.connection.indicator"
|
|
218
|
-
});
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
That is a good example of JSKIT's placement model working as intended.
|
|
222
|
-
|
|
223
|
-
`realtime` does not need to own your shell component. It just contributes one widget into an outlet that `shell-web` already exposed.
|
|
224
|
-
|
|
225
|
-
### `package.json` gets the runtime dependencies
|
|
226
|
-
|
|
227
|
-
The install also adds the runtime packages needed for transport:
|
|
228
|
-
|
|
229
|
-
- `@jskit-ai/realtime`
|
|
230
|
-
- `socket.io`
|
|
231
|
-
- `socket.io-client`
|
|
232
|
-
- Redis adapter dependencies for scaled deployments
|
|
233
|
-
|
|
234
|
-
That is why `npm install` is still required even though this chapter only touches a small number of app-owned files.
|
|
235
|
-
|
|
236
|
-
## Under the hood
|
|
237
|
-
|
|
238
|
-
The internal model is simple.
|
|
239
|
-
|
|
240
|
-
- the server provider mounts socket.io at `/socket.io`
|
|
241
|
-
- the client provider creates one shared socket client for the Vue app
|
|
242
|
-
- the shell status dot is registered as `realtime.web.connection.indicator`
|
|
243
|
-
|
|
244
|
-
On the server side, the package also publishes container tokens such as:
|
|
245
|
-
|
|
246
|
-
- `runtime.realtime`
|
|
247
|
-
- `runtime.realtime.io`
|
|
248
|
-
|
|
249
|
-
And on the client side it publishes:
|
|
250
|
-
|
|
251
|
-
- `runtime.realtime.client.socket`
|
|
252
|
-
|
|
253
|
-
If `REALTIME_REDIS_URL` is empty, the server uses a normal single-process socket.io server. If the URL is set, the package enables the Redis adapter so several Node processes can share realtime events.
|
|
254
|
-
|
|
255
|
-
That is the right level of abstraction for this package:
|
|
256
|
-
|
|
257
|
-
- generic transport in the runtime
|
|
258
|
-
- visible status in the shell
|
|
259
|
-
- actual event meaning left to the app or to later packages
|
|
260
|
-
|
|
261
|
-
## Summary
|
|
262
|
-
|
|
263
|
-
This chapter does not make the app look radically different, but it adds an important new capability.
|
|
264
|
-
|
|
265
|
-
- the backend can now host a realtime socket server
|
|
266
|
-
- the frontend can now keep one shared websocket connection alive
|
|
267
|
-
- the shell now exposes a live connection indicator
|
|
268
|
-
- later modules can build live behavior on top of that transport without inventing their own websocket setup
|