Guides
Two applications you build yourself, from install to green assertions.
Two applications, not two snippets
Everything else in these docs is a fragment sized to make a point. The two
guides are not: each one builds a real program — install the dependencies, write
the model, seed the grants, wire the routes, run the server, and verify every
decision twice, once with curl and once with assertions. A fragment cannot
show the order of the checks in a route, where request context comes from, or
what happens to a transaction when a document moves — and getting any of those
subtly wrong in a fragment is how a library ends up with a correct engine and an
unusable story.
Every TypeScript block below is type-checked against the real package on every build, and the assertion blocks are executed too: a guide whose decisions stop being true fails here rather than in a reader’s terminal.
The catalog
| guide | stack | the situation | what it teaches |
|---|---|---|---|
| A simple RBAC API | Hono, @tsbouncer/json-file | you are wiring this into a new service and want the smallest thing that works | the shape to internalise first: one idea, three types, and the whole access graph in a file you can read |
| A real-world documents API | Express, Drizzle ORM, SQLite | a product that outgrew owner_id | where the failures are: inheritance, exclusions, three conditions, a transactional move, and a list that agrees with a check |
Read them in that order. The first is deliberately plain; the second is deliberately accumulated, the way real access rules are.
How to work through one
Each guide follows the same arc: install, model, seed, caller, routes, run, verify. The verify step has two halves — a transcript of live requests, and an assertion script where silence is green. Keep both in your own app: the transcript shows the system working end to end, and the assertions pin the decisions so a later model edit that silently moves them fails loudly instead of shipping.
Related
- Wiring it into HTTP — the framework-agnostic shape these two follow
- ReBAC — the graph, in isolation
- Conditions — attribute-gated access, in isolation
- Stores — what the store actually has to do