tRPC over GraphQL / REST

Decision

tRPC for all internal API calls (workspace ↔ Route Handlers, CLI ↔ Route Handlers).

Why

• End-to-end types with zero codegen. Every procedure input/output is a Zod schema, and the client infers types straight from AppRouter.
• GraphQL solves a problem we don't have: heterogeneous clients requesting different fields. Every consumer of our internal API is TypeScript.
• REST + OpenAPI is a valid option for external SDKs later; we can expose select procedures via trpc-openapi on the day a non-TS consumer arrives.

Impact

When we'll add REST/GraphQL.

• Mobile SDK in Swift/Kotlin → expose a REST layer.
• Third-party integrations → GraphQL for field-selection control.

Related: 2026-07-23-nextjs.

Status

Accepted 2026-07-23. The implementation this chose was removed from the repository on 2026-08-12, when it became design-only. The decision has not been revisited since.

Sources

• The memory note decision-trpc-over-graphql, written 2026-07-23 and moved here on 2026-10-04. The text is the note's own; only the headings changed.