I Copy-Pasted Types Between Frontend and Backend for 6 Months. Then I Discovered RPC.

I have a confession to make.

For 6 months, I maintained two separate TypeScript codebases. My Next.js frontend had a types/api.ts file with 200+ lines of interfaces. My Express backend had an almost identical file. Every time I changed an API endpoint, I had to update both files. Every time I forgot, users got runtime errors.

I tried everything. I used Zod for runtime validation. I wrote integration tests. I even considered GraphQL (but the setup scared me). Nothing solved the core problem: My frontend and backend spoke different languages at compile time, even though they were both TypeScript.

The "Professional Developer" Tax

Here is what my workflow looked like with REST APIs:

01.Write an Express route: app.post('/api/users', ...)
02.Define the request body type in the backend
03.Copy that type definition to my frontend
04.Write a fetch wrapper with the "correct" types
05.Pray that I didn't make a typo
06.Wait for a bug report from users when I inevitably did

This is not how TypeScript is supposed to work. TypeScript promises compile-time safety. But the moment my data crosses the network, I lose all guarantees.

I am a student building production-grade apps for hackathons and my portfolio. I cannot afford to waste hours debugging type mismatches that TypeScript should have caught.

The RPC Revelation: Your Backend is Just Functions

Then I discovered RPC (Remote Procedure Call), specifically tRPC.

RPC is not new. It has been around since the 1980s. The idea is simple: What if calling a backend function felt exactly like calling a local function?

Traditional RPC frameworks like gRPC require .proto schema files and code generation. tRPC takes a different approach: It uses TypeScript's type system itself as the schema.

No code generation. No schema files. No manual type syncing. Just pure TypeScript inference.

The "Aha!" Moment

With tRPC, I define my backend procedures (functions) in TypeScript. My frontend automatically gets the types. If I change a function signature, my frontend build fails immediately with a TypeScript error—before I even run the app.

This is what I always wanted from TypeScript.

From REST Hell to RPC Heaven: The Migration

Let me show you the difference. Here is my old REST API code:

The Old Way (REST + Manual Types):

typescript

// Backend (Express)
app.post('/api/users', async (req, res) => {
  const { name, email } = req.body; // No type safety here
  const user = await db.users.create({ name, email });
  res.json(user);
});

// Frontend types (manually written, manually synced)
interface CreateUserInput {
  name: string;
  email: string;
}

interface User {
  id: string;
  name: string;
  email: string;
  createdAt: string;
}

// Frontend API call
const createUser = async (input: CreateUserInput): Promise<User> => {
  const res = await fetch('/api/users', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(input),
  });
  return res.json(); // Hope this matches the User type!
};

The problems:

Types are duplicated and manually maintained
No compile-time guarantee that request/response match
Every endpoint needs its own fetch wrapper
Runtime validation is separate from types

The New Way (tRPC):

typescript

// Backend (tRPC Router)
import { z } from 'zod';
import { router, publicProcedure } from './trpc';

export const appRouter = router({
  createUser: publicProcedure
    .input(z.object({
      name: z.string().min(1),
      email: z.string().email(),
    }))
    .mutation(async ({ input }) => {
      // input is automatically typed from Zod schema
      const user = await db.users.create(input);
      return user; // Return type is inferred
    }),
});

export type AppRouter = typeof appRouter;

typescript

// Frontend (Automatic types, zero configuration)
import { trpc } from './utils/trpc'; // We'll define this once

// Look at this beauty:
const { mutate } = trpc.createUser.useMutation();

mutate({
  name: 'John Doe',
  email: 'john@example.com',
  // TypeScript autocomplete works here!
  // If I add a required field in the backend, this breaks at compile time
});

What changed:

One source of truth: the backend procedure
Zod handles both validation AND type inference
Frontend gets full autocomplete and type safety
Zero manual type definitions
If the API changes, the frontend build fails immediately

The Setup: Easier Than You Think

Setting up tRPC in a Next.js project takes about 10 minutes. Here is the full setup I use:

Step 1: Install Dependencies

bash

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

Step 2: Initialize tRPC (Backend)

typescript

// src/server/trpc.ts
import { initTRPC } from '@trpc/server';

const t = initTRPC.create();

export const router = t.router;
export const publicProcedure = t.procedure;

Step 3: Create Your API (Backend)

typescript

// src/server/routers/appRouter.ts
import { z } from 'zod';
import { router, publicProcedure } from '../trpc';

export const appRouter = router({
  getUser: publicProcedure
    .input(z.object({ id: z.string() }))
    .query(async ({ input }) => {
      return await db.users.findById(input.id);
    }),
    
  createUser: publicProcedure
    .input(z.object({
      name: z.string(),
      email: z.string().email(),
    }))
    .mutation(async ({ input }) => {
      return await db.users.create(input);
    }),
});

export type AppRouter = typeof appRouter;

Step 4: Expose as Next.js API Route

typescript

// src/app/api/trpc/[trpc]/route.ts
import { fetchRequestHandler } from '@trpc/server/adapters/fetch';
import { appRouter } from '@/server/routers/appRouter';

const handler = (req: Request) => {
  return fetchRequestHandler({
    endpoint: '/api/trpc',
    req,
    router: appRouter,
    createContext: () => ({}),
  });
};

export { handler as GET, handler as POST };

Step 5: Create Client Hook (Frontend)

typescript

// src/utils/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import { AppRouter } from '@/server/routers/appRouter';

export const trpc = createTRPCReact<AppRouter>();

Step 6: Wrap Your App with Provider

typescript

// src/app/providers.tsx
'use client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { httpBatchLink } from '@trpc/client';
import { trpc } from '@/utils/trpc';
import { useState } from 'react';

export function Providers({ children }: { children: React.ReactNode }) {
  const [queryClient] = useState(() => new QueryClient());
  const [trpcClient] = useState(() =>
    trpc.createClient({
      links: [
        httpBatchLink({ url: 'http://localhost:3000/api/trpc' }),
      ],
    })
  );

  return (
    <trpc.Provider client={trpcClient} queryClient={queryClient}>
      <QueryClientProvider client={queryClient}>
        {children}
      </QueryClientProvider>
    </trpc.Provider>
  );
}

Step 7: Use It (Frontend Component)

typescript

'use client';
import { trpc } from '@/utils/trpc';

export default function UserProfile() {
  const { data, isLoading } = trpc.getUser.useQuery({ id: '123' });
  const createMutation = trpc.createUser.useMutation();

  if (isLoading) return <div>Loading...</div>;

  return (
    <div>
      <h1>{data?.name}</h1>
      <button onClick={() => {
        createMutation.mutate({
          name: 'Jane',
          email: 'jane@example.com',
        });
      }}>
        Create User
      </button>
    </div>
  );
}

That is it. You now have a fully type-safe API with zero manual type definitions.

The Hidden Features That Changed My Workflow

1. Request Batching (Zero Configuration)

tRPC automatically batches multiple requests made at the same time into a single HTTP call. If your component calls 3 different queries on mount, tRPC sends them as one request.

Why it matters: Reduces network overhead and improves performance, especially on slow connections.
Cost: Zero code changes. It just works.

2. React Query Integration (Caching & Refetching)

Because tRPC uses React Query under the hood, you get advanced features for free:

typescript

const { data, isLoading, refetch } = trpc.getUser.useQuery(
  { id: '123' },
  {
    staleTime: 5000, // Cache for 5 seconds
    refetchOnWindowFocus: true, // Refetch when user returns to tab
  }
);

3. Middleware for Auth (Context Injection)

You can add authentication middleware that runs before every protected procedure:

typescript

const protectedProcedure = publicProcedure.use(async ({ ctx, next }) => {
  const user = await getUserFromToken(ctx.req.headers.authorization);
  if (!user) throw new TRPCError({ code: 'UNAUTHORIZED' });
  
  return next({
    ctx: { user }, // Inject user into context
  });
});

export const appRouter = router({
  getProfile: protectedProcedure.query(({ ctx }) => {
    // ctx.user is typed and guaranteed to exist
    return { name: ctx.user.name };
  }),
});

4. Subscriptions (Real-Time Data)

tRPC supports WebSocket subscriptions for real-time features:

typescript

// Backend
export const appRouter = router({
  onUserUpdate: publicProcedure.subscription(() => {
    return observable<User>((emit) => {
      const interval = setInterval(() => {
        emit.next({ id: '1', name: 'Updated Name' });
      }, 1000);
      
      return () => clearInterval(interval);
    });
  }),
});

// Frontend
trpc.onUserUpdate.useSubscription(undefined, {
  onData: (user) => console.log('User updated:', user),
});

5. Monorepo Support (Share Types Across Projects)

Because tRPC types are just TypeScript, you can share your AppRouter type across multiple frontend projects (web, mobile, desktop):

text

my-monorepo/
├── packages/
│   ├── api/ (tRPC backend)
│   ├── web/ (Next.js, imports AppRouter)
│   ├── mobile/ (React Native, imports AppRouter)
│   └── shared/ (Zod schemas, shared utilities)

The Performance Story: tRPC vs REST vs GraphQL

Here is why I chose tRPC over other solutions:

vs REST: No manual type syncing. Request batching. Smaller payload (no redundant headers for multiple requests).
vs GraphQL: No schema files. No code generation. No learning curve. Smaller runtime (GraphQL libraries are heavy).
vs gRPC: No Protocol Buffers. No .proto files. Works over HTTP (no special infrastructure needed).

For TypeScript full-stack apps, tRPC hits the perfect balance of simplicity and power.

Conclusion: Type Safety Without the Friction

I spent 6 months fighting my tools. I knew TypeScript could prevent bugs, but I was manually bridging the gap between frontend and backend. I was doing the compiler's job.

tRPC gave me what I always wanted: end-to-end type safety with zero configuration.

Now, when I change an API function, my frontend build fails immediately. No more runtime surprises. No more "undefined is not an object" errors in production. No more copying types between files.

If you are building a TypeScript full-stack app and you are still using REST with manual type definitions, you are working too hard. RPC is not just a buzzword from the 1980s. With tRPC, it is the most productive way to build type-safe APIs in 2025.