How it works
With tRPC you write procedures on the server (queries, mutations and subscriptions), usually checking their input with Zod, and group them into a router. The client imports only the router's type, so every call from the browser is checked by the TypeScript compiler: rename a field on the server and the frontend stops compiling until it is fixed.
Under the hood it sends ordinary HTTP requests with JSON and can batch several calls into one. Adapters connect it to Next.js, Express, Fastify and serverless platforms, and it pairs with TanStack Query for caching on the client. It only works when both ends are TypeScript in the same codebase or monorepo, so it does not suit public APIs or apps written in other languages.
tRPC pros and cons
Pros
- End-to-end type safety with no schema or code generation
- Very quick to build with in a full-stack TypeScript app
- Changes that break the frontend are caught at compile time
Cons
- Both client and server must be TypeScript
- Poor fit for public APIs or third-party clients
- Couples the frontend tightly to the backend's code
When to use tRPC
Pick it when
- Full-stack TypeScript apps, such as Next.js with its own API
- Monorepos where one team owns both frontend and backend
Skip it when
- Other companies, languages or native mobile apps will call the API
tRPC pricing
tRPC vs the alternatives
Related terms
More in Backend and APIs
API styles