tRPC in production — when it works
tRPC gives type-safe APIs without OpenAPI or codegen. In a TS monorepo it's magic. In microservices it's the wrong tool.
tRPC lets you write APIs without descriptions (OpenAPI/Swagger) or code generation. The server type becomes the client type automatically through TypeScript.
When tRPC is great:
- Monorepo with one team writing both backend and frontend.
- Next.js full-stack apps.
- Internal tools without external consumers.
- Tight feedback loop — change API on Tuesday, frontend updates Wednesday.
When tRPC is wrong:
- API will be consumed by other clients — mobile native, partners, third-party SDKs.
- Frontend and backend teams ship at different cadences.
- Backend isn't TypeScript.
- You need RFC-style API documentation for compliance, partners, etc.
- Microservices with separate teams per service.
What teams overlook:
- tRPC is RPC, not REST. Different mental model. If your team has REST conventions, switching is non-trivial.
- Versioning isn't built in. Need to design your own version conventions.
- Documentation is worse than OpenAPI/GraphQL — schemas exist in code, not in standard formats.
- Caching at the HTTP layer (CDN, browser cache) doesn't fit tRPC patterns well.
For a Next.js + one product + one team — tRPC is a productivity boost. For anything else, REST + OpenAPI is usually a better default.