tRPC Protocol
Term 20 of 68 in the ERPStack technical glossary
What is tRPC Protocol?
tRPC is a protocol that allows developers to build end-to-end type-safe APIs without code generation by sharing TypeScript type definitions between the backend server and frontend client.
tRPC Protocol at a glance
- Model
- Typed remote procedure calls where 1 TypeScript 5.9 type definition serves client and server
- Code generation
- None — types are inferred, so there is 0 build step keeping 2 artefacts in sync
- Boundary
- Works when both ends share a repository; use REST or GraphQL for consumers you do not own
- Validation
- Zod 4 schemas at the procedure boundary, because types vanish at runtime
- Built with
- tRPC procedures in a Next.js 16 application, TypeScript 5.9 inference, Zod 4 validation, Drizzle ORM 0.45 over PostgreSQL 18, covered by Vitest 4 and Playwright 1.59
- Numbers that matter
- 1 type definition serving both ends; 0 code generation; 2 layers still needed, TypeScript 5.9 types and Zod 4 runtime validation
- Compare with
- REST endpoints, a GraphQL API Schema, or Next.js server actions
- Commonly paired with
- Zod, Drizzle ORM, React clients, Vitest and Playwright coverage
- Where it fits
- Internal B2B Software and SaaS products where 1 repository holds a Next.js 16 front end, Drizzle ORM 0.45 over PostgreSQL 18, and Vitest 4 and Playwright 1.59 covering both ends.
How tRPC Protocol works in production
The ERPStack approach to tRPC Protocol
We build all custom admin and user dashboards with tRPC, ensuring complete type safety from our database schemas directly to our React views.
Frequently asked questions about tRPC Protocol
What does the tRPC Protocol give you over REST?
End-to-end type safety with no schema artefact in between. The Protocol infers client types directly from the server's procedure definitions, so renaming a field breaks the build immediately rather than producing a runtime undefined in a component. There is no code generation step and no specification file to regenerate, which removes the most common source of drift between client and server.
When is tRPC the wrong choice?
When the consumer is not yours. The Protocol depends on the client importing types from the server, which requires a shared TypeScript codebase — so a public API, a partner integration or a mobile app in another language needs REST or GraphQL instead. Many systems use both: this for internal calls, a documented HTTP surface for everyone else.
Do types remove the need for validation?
No, and assuming they do is dangerous. TypeScript types are erased at runtime, so the Protocol still receives whatever bytes the network delivers. Validating input with a Zod 4 schema at the procedure boundary is what turns a static guarantee into a runtime one, and it also produces the error messages a client can act on rather than a stack trace.
How does this compare with server actions?
They overlap heavily inside a Next.js 16 application. Server actions cover the common case of a form or mutation invoked from a component with types intact, which is much of what the Protocol was solving. It remains useful for a richer procedure surface, for clients that are not React components, and where explicit routers and middleware are preferable to per-action functions.