trpc

TypeScript-first toolkit for building RPC APIs

weekly downloads671

versionv0.11.3

licenseMIT

categorybackend

Overview

tRPC is a TypeScript-first library for building remote procedure call (RPC) APIs that maintain complete type safety from server to client without schemas, code generation, or build steps. It leverages TypeScript's type inference to create a development experience where client code automatically knows the exact shape of server procedures, including inputs, outputs, and errors. When you call a server function from your client, you get IDE autocompletion and compile-time type checking as if the function were local.

The library emerged from the need to eliminate the friction of maintaining separate type definitions for API contracts in full-stack TypeScript applications. Traditional REST APIs require manual type synchronization or OpenAPI code generation, while GraphQL introduces schema definition languages and resolver complexity. tRPC solves this by exporting your server router's TypeScript type and using it to generate a typed client proxy that makes HTTP requests under the hood.

At its core, tRPC uses initTRPC() to create a router builder where you define procedures (queries and mutations) with optional input validation via Zod or similar libraries. The resulting appRouter type is exported and consumed by framework-specific client adapters for React, Next.js, Express, Fastify, SvelteKit, and more. The library has zero runtime dependencies and adds minimal bundle size, making it suitable for both new projects and incremental adoption in existing codebases.

tRPC is particularly popular in the Next.js and modern full-stack TypeScript ecosystem, where monorepo setups allow sharing types between frontend and backend code. It's production-ready with a stable API since v9, though the 0.11.3 version number suggests early release cycles. The library focuses on developer experience: changes to server procedures immediately surface as TypeScript errors in client code, and the lack of build pipeline requirements means rapid iteration.

Quick Start

typescript

import { initTRPC } from '@trpc/server';
import { z } from 'zod';
import { createHTTPServer } from '@trpc/server/adapters/standalone';
import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';

const t = initTRPC.create();

const appRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(({ input }) => {
      return { id: input.id, name: 'Alice', email: 'alice@example.com' };
    }),
  createPost: t.procedure
    .input(z.object({ title: z.string(), content: z.string() }))
    .mutation(({ input }) => {
      return { id: '123', ...input, createdAt: new Date() };
    }),
});

export type AppRouter = typeof appRouter;

createHTTPServer({
  router: appRouter,
}).listen(3000);

const client = createTRPCProxyClient<AppRouter>({
  links: [httpBatchLink({ url: 'http://localhost:3000' })],
});

const user = await client.getUser.query({ id: 'user_123' });
console.log(user.name);

const post = await client.createPost.mutate({
  title: 'Hello tRPC',
  content: 'Fully typed!',
});
console.log(post.createdAt);

Use Cases

Full-stack Next.js applications: Build API routes with tRPC routers and consume them in React components using the Next.js adapter, getting full type safety across your entire application stack without maintaining separate API type definitions.

Monorepo TypeScript projects: Share a single tRPC router type across multiple client applications (web, mobile, admin panels) in a workspace, ensuring all consumers stay synchronized with backend changes automatically through TypeScript's type checking.

Rapid prototyping and MVPs: Skip the overhead of designing REST endpoints or GraphQL schemas during early development stages. Define server functions directly and call them from the frontend with instant type inference, then refactor procedural boundaries later as requirements solidify.

Migration from REST in TypeScript codebases: Gradually replace REST endpoints with tRPC procedures in existing Express or Fastify applications, using tRPC's adapters to mount routers alongside traditional routes while gaining type safety for new features without rewriting everything.

Internal tools and admin dashboards: Build type-safe APIs for internal applications where you control both client and server, don't need public API documentation, and want maximum development velocity without the ceremony of formal API specifications.

Pros & Cons

Pros

+Complete end-to-end type safety with zero manual type definitions or code generation steps, drastically reducing type drift bugs
+Minimal runtime overhead with zero dependencies and tiny client bundle size, unlike heavier alternatives like GraphQL clients
+Excellent developer experience with instant IDE autocompletion, compile-time errors, and no build pipeline required for type updates
+Framework-agnostic core with official adapters for all major TypeScript frameworks, making integration straightforward
+Built-in input validation through Zod integration ensures runtime safety matches compile-time types

Cons

−Requires full TypeScript on both client and server; not suitable for polyglot architectures or consuming APIs from non-TypeScript clients
−Type inference depends on shared code access, making it impractical for public APIs or third-party integrations where clients need standalone SDKs
−Less mature ecosystem compared to REST or GraphQL with fewer third-party tools, middleware options, and community resources
−No built-in features for complex querying patterns like GraphQL field selection or REST content negotiation; purely procedural calls
−Version 0.11.3 indicates potentially unstable APIs compared to more mature RPC frameworks, though v9+ is considered production-ready

Alternatives

apollo-clientv2.6.10

A simple yet functional GraphQL client.

data-fetchingecmascriptes2015

403K / week

axiosv1.13.5

Promise based HTTP client for the browser and node.js

data-fetchingxhrhttp

82.9M / week

expressv5.2.1

Fast, unopinionated, minimalist web framework

backendexpressframework

67.4M / week

fastifyv5.7.4

Fast and low overhead web framework, for Node.js

backendwebframework

4.9M / week

Install

bash

npm install trpc

bash

pnpm add trpc

bash

bun add trpc

Overview

Quick Start

typescript

import { initTRPC } from '@trpc/server';
import { z } from 'zod';
import { createHTTPServer } from '@trpc/server/adapters/standalone';
import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';

const t = initTRPC.create();

const appRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(({ input }) => {
      return { id: input.id, name: 'Alice', email: 'alice@example.com' };
    }),
  createPost: t.procedure
    .input(z.object({ title: z.string(), content: z.string() }))
    .mutation(({ input }) => {
      return { id: '123', ...input, createdAt: new Date() };
    }),
});

export type AppRouter = typeof appRouter;

createHTTPServer({
  router: appRouter,
}).listen(3000);

const client = createTRPCProxyClient<AppRouter>({
  links: [httpBatchLink({ url: 'http://localhost:3000' })],
});

const user = await client.getUser.query({ id: 'user_123' });
console.log(user.name);

const post = await client.createPost.mutate({
  title: 'Hello tRPC',
  content: 'Fully typed!',
});
console.log(post.createdAt);

Use Cases

Pros & Cons

Pros

+Complete end-to-end type safety with zero manual type definitions or code generation steps, drastically reducing type drift bugs
+Minimal runtime overhead with zero dependencies and tiny client bundle size, unlike heavier alternatives like GraphQL clients
+Excellent developer experience with instant IDE autocompletion, compile-time errors, and no build pipeline required for type updates
+Framework-agnostic core with official adapters for all major TypeScript frameworks, making integration straightforward
+Built-in input validation through Zod integration ensures runtime safety matches compile-time types

Cons

−Requires full TypeScript on both client and server; not suitable for polyglot architectures or consuming APIs from non-TypeScript clients
−Type inference depends on shared code access, making it impractical for public APIs or third-party integrations where clients need standalone SDKs
−Less mature ecosystem compared to REST or GraphQL with fewer third-party tools, middleware options, and community resources
−No built-in features for complex querying patterns like GraphQL field selection or REST content negotiation; purely procedural calls
−Version 0.11.3 indicates potentially unstable APIs compared to more mature RPC frameworks, though v9+ is considered production-ready