tRPC in TypeScript: Simplify API Development Without Boilerplate

For most developers, building an API means choosing between REST and GraphQL, setting up routes or resolvers, and managing a separate schema to keep the frontend and backend in sync. It’s a familiar workflow, one that’s been refined over the years with tools, conventions, and plenty of boilerplate.

But when working in a TypeScript-first codebase, especially one where you control both the client and server, this approach starts to feel unnecessarily heavy. You’re writing types twice, wiring up handlers that mirror database functions, and dealing with schema drift that shouldn't exist in the first place.

This is the gap that tRPC fills. It doesn’t try to replace REST or GraphQL everywhere, but it does challenge the idea that an API layer always needs to be a separate contract. By leaning fully into TypeScript’s type system, tRPC offers a way to define backend procedures and instantly infer their types on the client without any code generation, schema stitching, or serialization layer in between.

The result is a lighter, more intuitive developer experience that feels like calling functions across files, not across a network.

API development has always involved some level of duplication, especially when trying to keep the frontend and backend in sync. In a typical REST setup, you define your route on the server, write a handler, and then manually create a corresponding fetch call on the client. If you're using TypeScript, you’ll probably also define the input and response types in a shared file or risk getting out of sync.

GraphQL improves this a bit by centralizing the schema, but now you’re managing resolvers, schema definitions, codegen, and possibly another layer like Apollo or urql. You’re still stitching together multiple parts just to send and receive a piece of data.

Take a simple example: creating a new user.

Even in this basic flow, there’s duplication in types, manual request handling, and room for drift. Change a field name on the server and forget to update the client? TypeScript won’t catch it unless you’re explicitly sharing types, which introduces its own overhead.

tRPC gets rid of this ceremony. You write a function once, on the server and the client automatically understands how to call it, what inputs it expects, and what it returns. No manual fetch calls. No custom hooks. No syncing types.

At its core, tRPC treats your backend like a collection of type-safe functions. Instead of defining endpoints or resolvers, you define procedures, which are functions that live inside routers. These routers group related logic together, and the entire structure can be consumed directly by the client, with full type safety.

A simple example looks like this:

Here, getById is just a function. It receives input (validated using Zod), runs server-side logic, and returns a result. No need to declare a route or response type separately, everything is inferred from the function itself.

The real magic happens on the client. After defining your procedures and grouping them into routers, you create an appRouter, essentially a central object that represents your entire backend API. This is passed into the tRPC server handler (like in a Next.js API route or app handler), which exposes the procedure tree to the client. From there, the client can import a trpc instance and start calling these procedures directly, with full type safety out of the box.

There’s no need to define getById on the client, or manually specify its input/output types. tRPC knows exactly what this function expects, because it’s inferred directly from the backend definition.

This model “define it once, use it everywhere” is what makes tRPC feel so different. It removes the artificial API boundary between server and client in projects where both are written in TypeScript. Instead of maintaining contracts, you’re just calling strongly-typed functions.

It’s not just about convenience; it’s about removing entire categories of bugs that stem from type mismatches and outdated API definitions.

tRPC works especially well in setups where the backend and frontend live in the same codebase, or at least speak the same language. That’s why it’s become a popular choice in full-stack TypeScript apps built with frameworks like Next.js, paired with an ORM like Drizzle for database access and React Query for frontend data fetching.

In these environments, tRPC doesn’t just simplify API calls, it removes the need to even think about them as “API calls” in the traditional sense. You're just calling functions with inputs and getting typed results back, whether you're working in a backend file or a frontend component.

It also integrates cleanly with tools you’re probably already using:

• Next.js: tRPC can be wired up to API routes or used with server handlers, making it a natural fit for apps built on the App Router or Pages Router.
• React Query: When paired with the @trpc/react-query adapter, procedures can be treated as fully type-safe queries or mutations—with caching, retries, and background refetching handled out of the box.
• ORMs: Since most modern ORMs (like Prisma, Drizzle, or Kysely) support static typing, combining them with tRPC creates a fully type-safe path from your database to your UI without needing to define types or schemas more than once.

The benefit isn’t just fewer lines of code, it’s clearer boundaries, safer data flow, and faster iteration. When everything speaks TypeScript, from your database to your frontend, you’re less likely to ship runtime bugs caused by broken contracts or outdated assumptions.

Like most tools in the TypeScript ecosystem, tRPC isn’t trying to solve everything for everyone, it’s optimized for a specific kind of project.

tRPC shines when:

• The frontend and backend are both written in TypeScript
• The same team controls both ends of the stack
• There’s no need for public-facing APIs or multi-language support
• Fast iteration, tight feedback loops, and strong type safety matter more than API versioning or schema generation

This makes it a great fit for:

• Internal tools and admin dashboards
• Full-stack TypeScript apps built with frameworks like Next.js
• Rapid prototypes or early-stage products
• Monorepos, where backend and frontend live in the same codebase

In these kinds of projects, tRPC often replaces traditional API layers with something that feels closer to function calls than network requests. You don’t need to think about routes, schemas, or response formats, just write the logic and let TypeScript handle the rest.

tRPC isn’t trying to replace REST or GraphQL across the board, but it does challenge some long-held assumptions about how API layers should be built.

REST is still the default for many teams, largely because of its simplicity and ubiquity. It works well when you need predictable URLs, clear separation between resources, and broad tooling support. GraphQL, on the other hand, offers flexibility and strong typing, especially useful when dealing with complex relationships or multiple consumers querying the same data differently.

But both come with trade-offs - schemas to maintain, types to sync, code to generate, and sometimes extra layers that don’t add much value when you’re working in a fully TypeScript-based stack. In apps where the frontend and backend are tightly coupled and written in the same language, the “API contract” starts to feel more like overhead than architecture.

tRPC takes a different route. It skips the schema and instead relies on TypeScript’s type inference to bridge the client-server gap. That means no manual type definitions, no GraphQL SDL, and no OpenAPI spec unless you explicitly need it. For internal tools, admin panels, or products built by small teams moving fast, this is often a worthwhile trade.

That said, tRPC isn’t a silver bullet. If you’re building a public API, need strong tooling support across multiple languages, or have complex API lifecycle requirements, REST and GraphQL are still better-suited. The goal isn’t to abandon those tools, but to recognize when they’re more complex than necessary for the problem at hand.

tRPC doesn’t reinvent APIs, it rethinks how we build them when the frontend and backend are both in TypeScript. By removing the need for separate contracts, schemas, or generated types, it reduces friction without compromising on safety. You’re still writing queries and mutations, but they feel more like calling functions than building API endpoints.

This shift works especially well in full-stack projects where speed, safety, and developer experience matter more than long-term API portability. It’s not trying to replace REST or GraphQL in every case but for a growing number of teams working in a shared TypeScript environment, it offers a more streamlined and intuitive alternative.

The next step is understanding what this new API layer makes possible. Whether it’s cleaner validation, reusable auth middleware, or a more scalable router structure, tRPC opens up patterns that deserve a closer look.