Use case · API
Service-only backends, typed end to end.
Hono + oRPC procedures typed from router to client. Drizzle on Postgres. The four sub-systems a service-only backend needs are wired into the registry before your first commit.
What's in the box
The four sub-systems a service-only backend needs.
Twelve capabilities grouped by the buyer-side question they answer. Pick a cluster, read what you actually ship.
Typed RPC
The wire format is the source of truth. Clients import the type; the server enforces it.
Router is the schema
Procedures live in TypeScript. Inputs, outputs, and errors flow from the router, not from a hand-written DTO. Rename a property and every client fails the build the same day.
End-to-end typed clients
Generated clients carry input/output types so call sites read like typed function calls. Refactors propagate through the typed layer instead of through stale documentation.
OpenAPI from the router
OpenAPI is generated from the same router the typed clients see. Partner integrations consume a spec that is actually in sync with the implementation, not a hand-trimmed copy.
typed-rpc
RequestoRPC
GET
contract: ORG_READ. auth: session
Response...
{
"id": "org_2nK9xR",
"name": "Acme Labs",
"plan": "pro",
"mrr": 1127,
"seats": 8,
"stripe_customer_id": "cus_R8x2Wq"
}Storage layer
The data shape that the contracts sit on top of. Swap providers without rewriting callers.
Drizzle by default
Schemas live in TypeScript alongside the contracts. Migrations run from the same CLI you ship to ops. Postgres by default, swap to MySQL or SQLite without rewriting the API surface.
Typed queries
Query builders carry the schema types end-to-end: a typo on a column name fails compilation. Tests use pg-mem so the test suite runs without a Postgres in CI.
Migration history
Migrations are generated, never hand-edited. Drift between schema and migrations is impossible because the same source produces both.
storage
$ drizzle-kit generate
4 schemas generated
$ drizzle-kit migrate
12 tables created
users . orgs . sessions . invoices ...
Auth & perimeter
Same auth and rate limits whether the caller is a user, a partner, or another service.
Auth on every procedure
Better Auth sessions validated per procedure. No global middleware that forgets to wrap the new route — the auth check is on the procedure definition itself.
Rate limits per route
Per-route rate limits with named buckets, so /search has a different ceiling than /webhook. Limits surface in the same dashboard as the rest of observability.
Service-to-service tokens
Internal callers get scoped, time-bound tokens with rotation. Audit log records every call, who issued the token, and which routes it has touched.
auth-and-perimeter
preview unavailable
Observability
When a partner files an integration ticket, you already know what changed.
OpenTelemetry traces
Every request, every DB query, every outbound call carries a trace ID. One OpenTelemetry pipeline; no second dashboard to monitor.
Errors tagged by procedure
Errors carry the procedure name and the input shape that caused them. Stack traces are usable; breadcrumbs are not a separate system.
Audit trail
Sensitive operations record the actor, the action, and the resource. Buyers in regulated verticals audit this in the first call; you don't have to explain what 'comprehensive logging' looks like.
observability
- GET /checkout142ms
- |auth.verify12ms
- |fetch45ms
- |db.query62ms
- -cache.set23ms
Stack
What runs on day one.
Hono
oRPC
Drizzle
Postgres
Process
How an API backend ships.
- Step 01
Define the contract
The router is the schema. Clients import the type, the server enforces it. No hand-written request/response DTOs.
- Step 02
Wire the storage layer
Drizzle on Postgres by default. Swap providers without rewriting the API surface — the schema stays the same.
- Step 03
Publish and iterate
OpenAPI is generated from the router. Clients consume the contract, not the implementation. Versioned deployments sit alongside the code.
Built on this
Four templates, each on its own surface.
Production-ready starter templates, each deployed at its own URL. Used as the reference set for what the registry can ship.
Explore
Related use cases.
Related
SaaS apps
Multi-tenant B2B SaaS with auth, billing, and a working dashboard on day one.
Read more
Related
Mobile backend
Auth, sync, and push notifications for native apps, on the same backend.
Read more
Related
AI products
RAG, chat, and agents wired against the same contracts your app uses.
Read more
Two doors
Use it yourself, or have us ship it for you.
Self-serve gives you the registry and the templates. Engagement gives you the team that built it. Pick the door that fits the timeline.