tRPC is the right choice for internal API calls in a TypeScript monorepo where both the client and server are yours. REST is the right choice for public APIs, mobile clients, and any scenario where you can’t guarantee a TypeScript client. Most SaaS products need both.
What Is tRPC?
tRPC (TypeScript Remote Procedure Call) lets you call server-side functions from the client with full TypeScript type safety — without writing an API schema, generating types, or maintaining documentation.
You define a procedure on the server:
// server/router.ts
export const appRouter = router({
user: {
byId: publicProcedure
.input(z.object({ id: z.string() }))
.query(async ({ input }) => {
return await db.user.findUnique({ where: { id: input.id } })
}),
},
})
export type AppRouter = typeof appRouter
You call it from the client with full autocomplete and type checking:
// client/UserPage.tsx
const { data: user } = api.user.byId.useQuery({ id: userId })
// `user` is fully typed — no manual type definitions needed
If you change the return type of user.byId on the server, TypeScript errors appear in every client callsite immediately.
What Is REST?
REST (Representational State Transfer) is the standard API architecture. HTTP verbs (GET, POST, PUT, DELETE) operate on resource URLs (/users, /users/:id). JSON in, JSON out. Works with any client in any language.
The Core Trade-Off
tRPC advantages:
- Zero boilerplate for type sharing between client and server
- No code generation step (unlike GraphQL)
- Autocomplete on all API calls — the IDE becomes your API documentation
- Excellent integration with React Query and Next.js
tRPC disadvantages:
- TypeScript on both client and server is required
- Not usable from a mobile app (React Native needs a wrapper), external services, or non-TS languages
- Tight coupling between client and server — they must be deployed together or versioned carefully
- No standard way to document the API publicly
REST advantages:
- Language-agnostic — any HTTP client can consume it
- Industry-standard with well-understood conventions
- OpenAPI/Swagger documentation is mature
- Easier for external developers and partners to integrate
REST disadvantages:
- Type safety requires code generation (OpenAPI → TypeScript) or manual maintenance
- More boilerplate — separate types on client and server
When to Use tRPC
Internal Next.js full-stack app: If your Next.js app is both the client and the server, tRPC is an excellent fit. You deploy one app, share types automatically, and write half the code.
Monorepo with TypeScript throughout: In a Turborepo setup where the frontend and backend share a types package, tRPC completes the picture by making API calls type-safe without code generation.
Rapid iteration on internal features: When you’re adding features fast and the API is only consumed by your own frontend, the friction of REST (define route, define response type, document it, generate client types) is real overhead that tRPC eliminates.
When to Use REST
Public API for external developers: If any external party will consume your API, REST is the right choice. REST is universally understood. Document it with OpenAPI/Swagger.
Mobile app clients: React Native can call tRPC but requires a bridge package and extra setup. Standard REST is simpler for mobile.
Microservices communicating across language boundaries: If your Python data pipeline calls your Node.js API, REST (or gRPC) is the right choice.
Webhooks: Incoming webhooks (from Stripe, GitHub, Twilio) are always REST — you can’t control how external services send data.
The Hybrid Approach (What We Use)
Most of our SaaS builds at Whipp Studio use both:
tRPC for internal API routes — dashboard data, user settings, feature-specific mutations. All consumed only by the Next.js frontend.
REST for public-facing endpoints — webhooks (Stripe, OAuth), public API endpoints if the product offers them, and mobile app integration.
This gives you the development speed of tRPC for internal work without sacrificing flexibility for external integrations.
Frequently Asked Questions
Can I use tRPC with Next.js App Router? Yes. tRPC v11 supports React Server Components and Next.js App Router. The integration is a bit more involved than with Pages Router but fully supported.
Is tRPC replacing GraphQL? For internal APIs where both client and server are TypeScript, tRPC has largely displaced GraphQL in the indie hacker and startup community. GraphQL’s advantage is its self-documenting schema and fragment-based querying, which matters more for large teams and public APIs.
Can I migrate from REST to tRPC? Yes. You can run tRPC alongside REST in the same Next.js project and migrate routes incrementally. There’s no need for a big-bang migration.
What’s the performance difference between tRPC and REST? Negligible. Both make HTTP calls. The difference is in developer experience, not request performance.
Does tRPC support WebSockets? Yes. tRPC supports subscriptions over WebSockets for real-time data. Useful for features like live notifications, collaborative editing, or real-time dashboards.
Choosing the right API architecture for your SaaS? At Whipp Studio, we make these decisions as part of every project — and we’ve seen what works and what doesn’t at scale. Book a free strategy call →