Add Backend

Add a backend (resources, data sources & presets)

The app is backend-agnostic by design: it reaches data and auth only through two seams, so adding a resource, swapping one resource's data source, or re-pointing the whole app at a different backend are all localized operations.

Routing rule: use add-backend whenever a screen needs its own data (a new entity/table, or a different backend); use add-component when composing UI on top of data that already exists.

Zero-config (bun dev, no DATABASE_URL) already runs on in-memory presets, so you can build UI before wiring a real backend. Full guides: docs/data-adapters.md, docs/backends.md.

Backend presets — ready-to-run templates

Six runnable backend templates ship in this skill's templates/<preset>/ (generated from the repo's backends/ source and contract-tested — templates/<preset>/README.md

• a shared CONTRACT.md). Pick one as the project's backend; each connects to the dashboard frontend through the two seams above — no page, query, table, or form changes — and each is independently verified.

The HTTP-API presets (the hono-* services + fastapi) all speak one shared wire contract, so their frontend auth providers ship pre-wired and typechecked in the base under src/lib/auth-providers/ (externalJwtAuthProvider, remoteBetterAuthProvider, remoteAuthjsProvider) — activating is a one-line swap. Supabase needs the Supabase SDKs, so its wiring ships as copy-ready files in templates/supabase/frontend-wiring/.

Stack matrix: framework (TanStack / Hono / FastAPI / Supabase) × ORM (Drizzle / Prisma / SQLAlchemy) × auth (better-auth / Auth.js / custom-JWT / Supabase). The presets are the idiomatic, verified combinations — not a blind cartesian product.

To stand up a preset:

1. Read references/<preset>.md (Add it / Foundation / Invariants / Verify).
2. Copy the template out as the service (cp -R templates/<preset> <dest>); follow its README to run it (zero-config: SQLite + a dev secret, one install + one run command).
3. Wire the frontend: bind the resource's server.ts to the preset's Repository adapter (§2) and point authProvider at the preset's AuthProvider (§3).
4. Verify end-to-end (the reference's Verify block).

The numbered sections below are the building blocks these presets compose: add a resource (§1), bind/swap a data source (§2), swap the auth preset (§3).

1. Add a CRUD resource

The CRUD table is the base archetype. products is the canonical reference; orders is a generated example.

1. Generate the vertical (table + feature + route + sidebar entry, auto-formatted):

   bun run create-resource <plural-name>   # e.g. customers

   This creates src/features/<name>/{schema,server,demo-data,queries,columns,config}.ts(x) and the route src/routes/_app/<name>.tsx, appends a Drizzle table to src/db/schema.ts, and inserts a sidebar item. Like products, the generated server.ts binds drizzleRepository when DATABASE_URL is set and falls back to memoryRepository over demo-data.ts otherwise — so the new resource runs under zero-config bun dev (no database) before you ever migrate.
2. Customise the fields in src/db/schema.ts (the appended pgTable) and in src/features/<name>/schema.ts (the zod input / form / list-params schemas). Keep numeric form fields non-coercing in *FormSchema (input must match the form value type); the server *InputSchema may coerce. Filter params that can be numeric must use z.coerce.string() (the router JSON-parses search params).
3. Adjust columns.tsx (cells, sortable columns), config.ts (filters, search placeholder), the server.ts repository config (searchColumns / sortColumns / filterColumns on the drizzle branch, and the matching searchFields / sortFields / filterFields on the memory branch), and the seed rows in demo-data.ts.
4. Migrate (only on Postgres — zero-config dev needs no DB): bun run db:generate && bun run db:migrate.
5. Verify: bun run typecheck && bun run check && bun run test, then open /<name> (it lists the demo-data.ts rows with no DB).

Resource invariants (must hold)

• Every server-fn handler calls requireUser() first and validates input via .validator((data) => zodSchema.parse(data)) (an arrow wrapper, not a bare zodSchema.parse method reference).
• List state lives in the URL (validateSearch + useTableSearch); never local useState.
• Mutations show a toast and invalidate the resource's query keys; deletes go through useConfirm().
• The repository binding lives in server.ts (server-only): drizzleRepository from @/infra/data/drizzle-repository behind hasDatabase, with a memoryRepository fallback for zero-config dev — never imported from a client component.
• The page wraps DataTable in a full-height flex column — <div className="flex h-full flex-col gap-6"> with the header as shrink-0 — so the pagination bar pins to the bottom (the shell sizes each page to the viewport). The generator emits this; keep it.