@samebase/alchemy-convex 0.14.1 → 0.16.0

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/README.md CHANGED
@@ -167,7 +167,8 @@ values explicitly: `Convex.providers(Convex.fromValues({ accessToken, deployKey
167
167
  ## State in Convex
168
168
 
169
169
  `state: Convex.state({ team })` keeps the Alchemy state of every stack and stage of a Convex team in
170
- one project of that team, `samebase`, so a repository holds one secret and a stack can create
170
+ one project of that team, `alchemy-state-store`, the same name as the Cloudflare state store of
171
+ Alchemy, so a repository holds one secret and a stack can create
171
172
  and destroy its own project. [docs/design/convex-state.md](docs/design/convex-state.md) records the
172
173
  decisions and the measurements.
173
174
 
@@ -185,26 +186,16 @@ Every run needs the team token in `CONVEX_ACCESS_TOKEN`, or the Convex CLI login
185
186
  team access token names its team, so `Convex.state()` needs no `team` with one; a `team` slug that
186
187
  is set must be the slug of that team, checked against its projects, and a token of another team
187
188
  fails the run. The Convex CLI login needs the slug or the id. The first run of a team creates
188
- the project `samebase` and pushes the store app of this package to its
189
+ the project `alchemy-state-store` and pushes the store functions to its
189
190
  production deployment with the Convex CLI of the app; a later version of this package pushes a
190
- newer store app when it finds an older one. A store that is newer than the package fails the run
191
- with both versions, so the repositories of a team upgrade the package together. Each run makes a
191
+ newer store when it finds an older one. A store that is newer than the package fails the run with
192
+ both versions, so the repositories of a team upgrade the package together. Each run makes a
192
193
  deploy key of that deployment that can only run the store's internal functions, and deletes it at
193
194
  the end. Rows are in the tables `resources` and `outputs` of the component `alchemyState` in the
194
195
  dashboard, under the stack name.
195
196
  The store has no lock: run one deploy of a stage at a time, such as with a CI concurrency group.
196
197
  The store and its readers (Samebase) are released and upgraded together.
197
198
 
198
- The base app of a team can serve the store in the `samebase` project, next to its own components.
199
- It mounts the component from `@samebase/alchemy-convex/state/convex.config`. It exports the
200
- store functions of `@samebase/alchemy-convex/state/functions`:
201
- `stateFunctions(components.alchemyState, "base")` and `readerFunctions(components.alchemyState)`.
202
- It exports its auth config from `@samebase/alchemy-convex/state/auth.config`. Then
203
- `state:host` answers `"base"`, and `Convex.state()` never pushes over that app: a base
204
- that is older than the package fails the run with `OutdatedBase`, and the base app upgrades its
205
- `@samebase/alchemy-convex`. See
206
- [the design note](docs/design/convex-state.md#the-stores-functions-are-exported-and-a-base-is-never-pushed-over-0140).
207
-
208
199
  Store version 3 supports native subscriptions. A trusted server checks repository access, then
209
200
  calls internal `reader:authorize({ repository, subject })` with a deployment credential. It gives
210
201
  the returned token to a separate `ConvexClient` connected to the state deployment. The client
@@ -283,6 +274,24 @@ call.
283
274
  as the build inputs `["src/**", "public/**", "vite.config.ts"]`. A minted key for a command
284
275
  has every action, because the command can do more than a push.
285
276
 
277
+ - `Convex.HubClient`: `{ team, app, redirectUri, deploymentType, clientName, softwareVersion? }`
278
+ registers one deployment as a client of the identity hub of the team. The hub is the production
279
+ deployment of the project `samebase`. The resource finds it by name and runs
280
+ its internal function `identityBroker:registerClient` with a short-lived key, so the stack needs no
281
+ other credential and no hub address. The first client of an `app` creates the app. Outputs
282
+ `issuer`, `clientId`, `clientSecret`, `redirectUri`, `deploymentType`, and `clientName`, which the
283
+ `env` of the `Convex.Deployment` writes to the deployment. Another `redirectUri` is a new client, and
284
+ a destroy deletes the client.
285
+
286
+ A development deployment has no stack, so the package has a command for it. Run it in the directory
287
+ of the app, before the first push: it registers the deployment of that directory with
288
+ `CONVEX_ACCESS_TOKEN` or the Convex CLI login, and writes `HUB_ISSUER`, `HUB_CLIENT_ID`, and
289
+ `HUB_CLIENT_SECRET` to it. A deployment with all three variables keeps them.
290
+
291
+ ```sh
292
+ npx alchemy-convex hub-client --team my-team --app scout --callback-path /auth/hub/callback
293
+ ```
294
+
286
295
  ## Data safety
287
296
 
288
297
  - `Convex.Project` and `Convex.Deployment` have the removal policy `retain`. `alchemy destroy`