The Problem tRPC Solves

When you build a REST API in TypeScript, the server defines the response shape. The client must manually create matching TypeScript types. These types drift over time as the API evolves, and the compiler cannot catch the mismatch because the types are defined in separate packages.

A renamed field on the server becomes a silent runtime bug on the client.

GraphQL solves type drift by generating TypeScript types from the schema using tools like graphql-codegen. This works well but adds complexity: a separate query language (GraphQL SDL), a code generation step in the build pipeline, and schema management tooling.

For teams already invested in GraphQL, codegen is the right answer. For teams that want type safety without the GraphQL overhead, tRPC offers an alternative.

tRPC's approach is radical in its simplicity: define your API procedures on the server as TypeScript functions, export the router type, and import that type on the client. No code generation. No separate schema language.

The TypeScript compiler itself enforces the contract between client and server at build time.

tRPC requires the server and client to share types via TypeScript imports. This works naturally in a monorepo (Turborepo, Nx, pnpm workspaces) where server and client are separate packages that can import from each other.

For a fully separate backend and frontend, you would need to publish the router types as a shared package, which adds a publishing step but is still codegen-free.

On the server, you define a router and export its type: export type AppRouter = typeof appRouter. On the client, you import that type and create a typed client: createTRPCReact(). The client knows exactly what procedures exist and what their input and output types are.

Renaming a procedure on the server immediately shows a TypeScript error on the client.

Because tRPC uses TypeScript's type system directly, your editor provides full autocomplete for procedure names, input shapes, and return types on the client side. Renaming a procedure is a TypeScript rename refactor, not a manual search-and-replace across the codebase.

This developer experience improvement is tRPC's most praised feature in practice.

By default, tRPC uses HTTP as its transport. Each procedure call is an HTTP request. tRPC also supports WebSockets for subscriptions. The transport is an implementation detail; the client API is identical regardless of transport.

You can also expose tRPC procedures as conventional REST endpoints using the REST adapter for compatibility with non-tRPC clients.

tRPC works as middleware in Express, Fastify, and Hono. For Next.js, it integrates via API route handlers. The create-t3-app starter (T3 Stack) bundles tRPC, Prisma, NextAuth, and Tailwind into a full-stack Next.js template.

The T3 Stack is the most popular tRPC starting point and demonstrates production-ready patterns.

Another type-safe REST approach is to define Zod schemas, auto-generate an OpenAPI spec, and generate TypeScript types from the spec. This provides an API contract consumable by non-TypeScript clients.

tRPC is simpler but TypeScript-only. OpenAPI+Zod adds complexity but produces a public API contract. Choose tRPC for internal TypeScript-to-TypeScript communication; choose OpenAPI for public APIs.

tRPC is not a replacement for REST when you need a public API consumed by third parties, mobile clients not written in TypeScript, or partners who need a stable versioned contract. It is specifically for TypeScript monorepos with full-stack type safety.

Understanding this scope prevents adopting tRPC in contexts where REST or GraphQL is the better fit.

Running npm create t3-app@latest scaffolds a Next.js project with tRPC, Prisma, NextAuth.js, Tailwind CSS, and TypeScript pre-configured. The generated code demonstrates the router structure, context creation, and client setup.

Studying this scaffold is the fastest path to understanding how all the tRPC pieces fit together in a real application.

How does tRPC share types between the server and client without code generation?

tRPC solves type drift between TypeScript client and server by sharing the router's TypeScript type directly via import, eliminating code generation. It works in monorepos and integrates with Next.js, Express, Fastify, and Hono. The T3 Stack (create-t3-app) is the standard production starter.

tRPC is TypeScript-only and best suited for internal full-stack applications, not public APIs.