Fixture to contract workflow

File-backed JSON data, from fixture to production contract.

Start with db/*.json, infer useful schema metadata, serve local REST and viewer routes, then graduate each resource behind stable operation refs when production constraints appear.

Browse advanced settings Read operations guide

install

Start from a package install.

pnpm add @async/db
pnpm exec async-db sync
pnpm exec async-db serve

Keep serve running, then open http://127.0.0.1:7331/__db.

npm install @async/db
npx async-db sync
npx async-db serve

Use npx to run the local package binary after install.

Ask Codex to install the package and wire up the first local data workflow:

Install @async/db in this repo with the current package manager.
Add scripts for db, db:sync, and db:serve.
Create db/users.json with one seed user.
Run async-db sync and report the viewer URL.

db/users.json fixture

[
  {
    "id": "u_1",
    "name": "Ada",
    "plan": "founder"
  }
]

sync output schema + types

User.plan enum

GET /db/users.json route

production boundary resource-level

json sqlite postgres ops refs

01 fixture

Editable source files in `db/`.

02 contract

Inferred or explicit resource schema.

03 local API

REST, GraphQL metadata, and viewer state.

04 graduate

Registered operations and store choices.

Advanced pages for the settings that change production behavior.

The public docs now have separate pages for the settings developers need after the first fixture works: config, schema strictness, runtime stores, server exposure, operations, mocks, and generated artifacts.

db.config.mjs

Configuration map

Folders, outputs, route bases, resource overrides, and strictness.

stores

Runtime stores

Default JSON state, source-file writes, SQLite, Postgres, KV, Redis, and custom stores.

operation refs

Registered operations

Allowlisted REST or GraphQL templates, generated refs, and route lockdown.

.db + generated

Generated files

What stays ignored, what can be committed, and which examples do it.

Keep local routes local, then expose reviewed operations.

Use fixture-like routes while the data shape is moving. When the app-facing contract settles, move browser traffic to registered operation refs, app-owned auth, and explicit route exposure rules.

GET /db/users.json POST /__db/operations/GetUserProfile server.expose.rest = "registered-only" server.expose.viewer = "dev"

Operation refs are allowlist identifiers, not secrets. They keep route shape reviewable while normal app policy still owns authentication, authorization, limits, and monitoring.

Example paths stay visible.

The docs point readers toward concrete repo examples instead of abstract feature claims.

See the advanced map

basic advanced production-json local-web-app schema-manifest schema-ui rest-client standard-schema