English for tRPC

tRPC’s entire pitch is a single idea — end-to-end type safety without code generation — and discussing it well means being able to explain that idea precisely, since it’s easy to conflate with GraphQL or OpenAPI at a glance.

Key Vocabulary

End-to-end type safety — the property that a change to a backend procedure’s input or output type immediately shows as a type error on the frontend, without a schema file, code generation step, or separate client library to keep in sync. “This is what people mean by end-to-end type safety with tRPC — I changed the return type on the backend procedure, and my editor immediately flagged the frontend code using it as a type error, with no code generation step in between.”

Procedure — a single backend function exposed through tRPC, either a query for reading data or a mutation for writing it, roughly analogous to a REST endpoint or a GraphQL resolver but defined as plain TypeScript. “We added a new procedure called getUserSettings — it’s just a TypeScript function on the backend router, but the frontend can call it directly with full type inference, no separate endpoint definition needed.”

Router — a collection of related procedures grouped together, which can be nested to organize an API by domain, and which the frontend imports the type of to get full autocomplete and type checking. “The user router groups all user-related procedures together — get, update, delete — and we import just its type on the frontend, which is how the client gets full autocomplete without importing any backend code.”

No code generation — the fact that tRPC achieves type safety by directly importing TypeScript types across the client-server boundary, unlike GraphQL or OpenAPI-based tools that generate client code from a schema. “Unlike our old GraphQL setup, there’s no code generation step here — we’re not running a codegen command after every schema change, the type just flows directly from the backend router type import.”

Input validation (via Zod) — the common pattern of pairing tRPC procedures with a schema validation library like Zod to validate runtime input, since TypeScript types alone only provide compile-time safety, not runtime checks. “TypeScript types disappear at runtime, so we still need input validation with Zod on this procedure — it’s what actually rejects a malformed request at runtime, the TypeScript type only helps at compile time.”

Common Phrases

• “Is this actually end-to-end type safety, or do we still have a manual sync step somewhere?”
• “Should this be a new procedure, or does it belong on an existing one?”
• “How should we organize these procedures into routers?”
• “Do we need input validation here, or are we relying on TypeScript types alone at runtime?”
• “Are we sure there’s no code generation step hiding somewhere in this setup?”

Example Sentences

Explaining the core value proposition: “The reason we picked tRPC over a REST API here is end-to-end type safety — when the backend procedure’s shape changes, the frontend gets a compile error immediately, instead of a runtime failure we’d only catch in testing or production.”

Clarifying an API design question: “This should probably be a separate procedure rather than an extra parameter on the existing one — it’s a genuinely different operation, and splitting it keeps each procedure’s input and output types clean and specific.”

Correcting a common misunderstanding: “TypeScript types don’t protect us at runtime — someone could still send malformed JSON to this procedure. We need actual input validation with Zod here, the compile-time type alone isn’t a security boundary.”

Professional Tips

• Lead with end-to-end type safety when explaining why tRPC was chosen — it’s the single feature that most differentiates it from REST and even from GraphQL without codegen.
• Design each procedure around one clear operation, rather than overloading it with many parameters and conditional behavior — it keeps input and output types meaningful.
• Organize routers by domain, not by HTTP verb — group all operations on a resource together rather than splitting by query versus mutation across separate files.
• Emphasize no code generation when comparing to GraphQL setups that require running a codegen step after every schema change — it’s a real developer-experience difference, not just marketing.
• Never skip input validation just because TypeScript types exist — pair procedures with Zod or an equivalent schema validator for actual runtime safety.

Practice Exercise

1. Explain what “end-to-end type safety” means and why it doesn’t require code generation in tRPC.
2. Describe the difference between a procedure and a router.
3. Write a sentence explaining why input validation is still needed even with TypeScript types.