Learning tRPC - Modern Tooling & the Latest Stable Features

#Introduction

This is the final episode of the Learning tRPC journey. Episode 18 summarizes the modern tooling and stable features you've been using, then looks ahead: how tRPC fits into production trends such as full-stack type safety, monorepos, and API-first DX.

This isn't just a list — it's a map of how you can use everything you've learned to build applications that are type-safe from end to end.

#Modern tRPC Tooling

#The Four Packages You Should Know

The entire series uses an ecosystem made up of four main packages:

• @trpc/server: router, procedure, middleware, adapter, and TRPCError.
• @trpc/client: createTRPCProxyClient, createTRPCClient, and all the links.
• @trpc/react-query: createTRPCReact for React hooks.
• @trpc/next: createTRPCNext for Next.js pages router integration.

npm install @trpc/server @trpc/client @trpc/react-query @trpc/next
npm install zod @tanstack/react-query

Each package has a single responsibility. Understand its boundaries so your imports are always correct: server adapters in @trpc/server/adapters/..., links in @trpc/client, and hooks in @trpc/react-query.

#createTRPCProxyClient in Various Contexts

createTRPCProxyClient is tRPC's entry point outside React. It is used for scripts, microservices, and even cloud functions:

import { createTRPCProxyClient, httpBatchLink } from "@trpc/client";
 
const trpc = createTRPCProxyClient<AppRouter>({
  links: [
    httpBatchLink({
      url: "http://api.internal:3000/trpc",
      headers: () => ({ Authorization: `Bearer ${getToken()}` }),
    }),
  ],
});
 
export async function ambilDashboard(userId: number) {
  const [user, stats] = await Promise.all([
    trpc.user.byId.query({ id: userId }),
    trpc.user.stats.query({ id: userId }),
  ]);
  return { user, stats };
}

One router definition, consumed from anywhere: React, the server, or edge functions — always with the same types.

#Stable Features and Conventions in tRPC v10+

#router.merge for Modular Routers

router.merge lets you merge other routers without changing their original structure — ideal for combining routers from separate packages:

import { router } from "./trpc";
import { adminRouter } from "./routers/admin";
import { userRouter } from "./routers/user";
 
const appRouter = router({
  user: userRouter,
});
 
const fullRouter = appRouter.merge(adminRouter);

appRouter.merge(adminRouter) merges all the procedures of adminRouter into the existing router. This keeps per-domain code splitting (and lazy loading from episode 13) clean without sacrificing a single API contract.

#procedure.input/output and Links

The stable conventions used throughout the series:

• .input(schema) — validates and types the arguments.
• .output(schema) — validates the response and types the output.
• .query(), .mutation(), .subscription() — the three procedure types.
• .use(middleware) — behavior composition.

Completed with links:

const links = [
  loggerLink({ enabled: () => isDev }),
  splitLink({
    condition: (op) => op.type === "subscription",
    true: wsLink({ url: wsUrl }),
    false: httpBatchLink({ url: trpcUrl }),
  }),
];

The pattern above is the standard links configuration you've been using since episode 6: logger in development, subscriptions via WebSocket, everything else HTTP batch.

#Production Trends with tRPC

#Full-Stack Type Safety

tRPC is the face of the full-stack type safety movement: one language (TypeScript) and one type system for the whole application. Contract errors are caught at compile time, not in production. This trend keeps strengthening — from new libraries to frameworks like Next.js and Astro that are all increasingly TypeScript-first.

#Monorepo Integration

tRPC thrives in monorepos. A common structure with pnpm workspaces or Turborepo:

apps/
├── web/        # Next.js + @trpc/react-query
└── api/        # server tRPC
packages/
├── server/     # router + procedure bersama
└── shared/     # schema zod yang dipakai lintas app

With a monorepo, schema changes in packages/shared are immediately visible and validated across all consumers — one change, the entire contract updated.

#API-First DX

tRPC redefines the developer experience: no codegen, no stale documentation, no sync steps. The API is plain TypeScript code, and the editor becomes documentation that is always accurate. This is the direction the modern JavaScript ecosystem is following.

#Conclusion

Episode 18 closes the series with a complete summary: the four tRPC tooling packages, stable features such as router.merge, procedure.input/output, and links, and production trends — full-stack type safety, monorepos, and API-first DX — that make tRPC a natural choice for modern TypeScript applications.

Key takeaways:

• Know the role of the four packages: server, client, react-query, and next.
• createTRPCProxyClient connects tRPC to non-React contexts.
• router.merge keeps routers modular within a single API contract.
• .input and .output are the backbone of type safety.
• Monorepos maximize shared types across applications.
• tRPC is a real implementation of full-stack type safety.

And so ends the 19-episode Learning tRPC journey: from prerequisites, architecture, and your first API to production deployment and the latest trends. You now have what it takes to build full-stack TypeScript applications that are type-safe from end to end. Apply it in real projects, and may every successful compile be proof that your contracts are always in sync. Happy building!