Scenario 01
If your whole stack is TypeScript in one monorepo…
tRPC gives end-to-end type safety without code generation.
Comparison: GraphQL / REST vs. tRPC
GraphQL vs. REST vs. tRPC: choosing an API architecture
Choose between flexible multi-client GraphQL, universal REST and end-to-end type-safe tRPC for an all-TypeScript stack.
Decision framework
Which one fits your situation
Scenario 02
If you serve mobile apps or third-party developers…
GraphQL or REST gives you language-neutral contracts.
Trade-offs
Side by side
How the two options compare on the dimensions that usually decide this choice.
| Dimension | GraphQL / REST | tRPC | Verdict |
|---|---|---|---|
| Type safety | Generated from the schema (GraphQL codegen or OpenAPI) | Inferred directly from server code, with no codegen step | tRPC is simplest for all-TypeScript stacks |
| Client languages | Any language: Swift, Kotlin, Python, Go, web | TypeScript clients only | GraphQL and REST suit polyglot systems |
| Over-fetching | Clients request exactly the fields they need (GraphQL) | The server procedure defines the response shape (tRPC, REST) | GraphQL gives clients the most control |
Questions
Frequently asked questions
The frontend calls backend procedures like local functions, with autocomplete and compile-time errors whenever the contract changes.
Yes. Routers can be split by domain and merged into one root router. The real limit is organizational: it assumes TypeScript on both sides of the API.
Talk the decision through with an engineer
Share your constraints — team, traffic, budget, compliance. We'll reply within one business day, and the call is about your decision, not our preferred stack.