Why I Switched from REST to tRPC
End-to-end type safety changed how I think about API contracts. Here's the migration story, trade-offs, and what I'd do differently.
The Friction of Traditional REST in TypeScript
For years, standard full-stack development followed a familiar pattern: write a backend endpoint with Express or Fastify, validate the payload with Zod or Joi, create a matching TypeScript interface on the frontend, and write a fetch wrapper. Despite best intentions, frontend and backend types inevitably drift out of sync over time, leading to dreaded runtime errors like 'undefined is not an object' in production.
What Makes tRPC Different
tRPC completely eliminates the API client generation and manual typing step. By inferring TypeScript types directly from server router definitions, your client code gets instant autocomplete, hover documentation, and compile-time validation for all queries and mutations without any code generation build step.
// Server router definition
export const appRouter = router({
getProjectBySlug: publicProcedure
.input(z.object({ slug: z.string() }))
.query(async ({ input }) => {
return await db.project.findUnique({ where: { slug: input.slug } });
}),
});
// Frontend consumption with 100% type inference
const { data, isLoading } = trpc.getProjectBySlug.useQuery({ slug: "orbit-analytics" });Trade-offs and When to Stick with REST
tRPC is not a silver bullet for every project. Because it requires a shared TypeScript codebase between client and server, it is best suited for full-stack TypeScript monoliths or monorepos (Next.js, Turborepo). If you need to expose public third-party APIs or integrate with mobile apps built in Swift/Kotlin, OpenAPI/REST or GraphQL remains the standard.
Key Takeaways from the Migration
Switching to tRPC reduced our API-related bug count by over 70% and drastically increased our team's refactoring velocity. Being able to rename a database column and instantly see red squigglies across all affected frontend components is an unmatched developer experience.