tRPC: end-to-end types with no codegen, and what that costs

The whole trick: typeof appRouter

On the server you build a router. Its type — not its value — encodes every procedure name, input, and output. You export that type and hand it to the client as a generic:

// server/router.ts
import { initTRPC } from "@trpc/server";
import { z } from "zod";
const t = initTRPC.create();

export const appRouter = t.router({
  getUserById: t.procedure
    .input(z.object({ id: z.number(), includeDeleted: z.boolean() }))
    .query(({ input }) => findUser(input.id)), // returns User
});

export type AppRouter = typeof appRouter; // ^? the entire router's type

// client/trpc.ts
import { createTRPCClient, httpBatchLink } from "@trpc/client";
import type { AppRouter } from "../server/router"; // type-only — see below

const trpc = createTRPCClient<AppRouter>({ links: [httpBatchLink({ url: "/trpc" })] });

const user = await trpc.getUserById.query({ id: 42, includeDeleted: false });
// ^? User  — inferred end-to-end from the server's return type
// trpc.getUser  // Error: Property 'getUser' does not exist

createTRPCClient<AppRouter> takes the server router type and, through a large internal mapped/conditional type, transforms it into the client’s call interface: appRouter’s getUserById.query procedure becomes trpc.getUserById.query(input): Promise<output>. The input type comes from your zod schema’s z.infer; the output type comes from the resolver’s return type. Both flow to the client with zero generated files. (In a real app you rarely call .query directly — you feed it through a client cache like React Query, where these inferred types carry through to your hooks; see the Frontend track on client caches.)

”No codegen” — what it actually means and its hard limits

Before you reach for tRPC on your next project, ask: can my client always import type from the server? If the answer is yes, you get live inference for free. If the answer is no, you need a wire contract — and that changes everything.

REST + OpenAPI generates a client.ts file from a spec; GraphQL generates types from a schema. tRPC generates nothing. The trade is that the client must be able to import type the server’s AppRouter — which means:

• Same TypeScript build / monorepo. Client and server compile together (or the server ships a .d.ts the client consumes). There is no wire format describing the API; the type is the contract, and a type can only cross a compile boundary, not a network or language one.
• TypeScript on both ends. A Swift or Kotlin client cannot consume a TS type. For polyglot or third-party consumers you need a real wire contract — OpenAPI or GraphQL — which is exactly when their codegen pays off.

The cost: router inference time and editor lag

That convenience is paid for in compiler work. The client’s type is a function of the entire server router type, recomputed by tsc and the editor’s language service. On a router with hundreds of procedures, deeply nested sub-routers, and complex zod schemas, you feel it: hover tooltips that spin, autocomplete that lags, tsc runs that crawl. The inference doesn’t get cached the way a generated file would — there is no file. Mitigations:

• Split into sub-routers and avoid one monolithic 500-procedure router; smaller units re-infer faster.
• Annotate procedure return types explicitly so the resolver’s output type doesn’t have to be inferred through your whole data layer each time.
• Keep zod schemas reasonable — a giant z.discriminatedUnion with 40 members is expensive to infer everywhere it’s used.
• Reach for codegen when inference stops scaling: this is a genuine point where OpenAPI/GraphQL’s “generate once, read a file” model wins on compiler performance, trading live inference for a build step.

Together these mitigations reduce the re-inferred surface area; without them a 500-procedure monolith makes the entire language service crawl on every keystroke.

The one footgun: importing server runtime by accident

Because the server and client live in one repo, it is easy to write import { appRouter } (value) instead of import type { AppRouter } (type). The value import drags the entire server runtime — database drivers, secrets, Node-only modules — into the client bundle, and may even ship credentials to the browser. Always import type for the router on the client. Enable "verbatimModuleSyntax": true (unit 07) so a stray value-import of a type is a compile error, not a silent bundle bloat.