For a long time, tRPC was the top choice in the TypeScript world. It solves a problem that every full-stack developer faces: how to keep backend logic and frontend types in sync without writing endless schemas or fighting with code generators. It was fast, elegant, and simple. Teams that lived inside Typescript picked it up and rarely looked back.

Then oRPC came into play. It borrowed the parts developers loved about tRPC, but pushed for a more advanced idea. It maintained the same clean, type-safe workflow but added something tRPC never aimed for, which is first OpenAPI support. All of a sudden, the same functions that powered your TypeScript client could also power Python services, mobile apps, or third-party integrations without extra work.

This dilemma raises an important question for many developers: If both tools share the same foundation, which one should power your next project? And more importantly, what edges does each framework bring when you look past the surfaces?

In this article, we’ll examine how each framework performs in practice, highlighting where each one excels, and the circumstances in which one choice is far more sensible than the other.

🚀 Sign up for The Replay newsletter

The Replay is a weekly newsletter for dev and engineering leaders.

Delivered once a week, it’s your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.

What are RPC frameworks?

Before comparing the two, let’s quickly recap what RPC frameworks actually do and how they fit into modern backend communication.

An RPC (Remote Procedure Call) allows one application (the client) to execute a function on another machine (the server) as though it were running locally. Instead of sending HTTP requests, parsing JSON, or handling routes manually, the client calls a remote function directly. Think of it like calling a function in your local codebase, only this time the computation happens on a remote server while the framework quietly handles the networking and data exchange for you.

To illustrate this, consider the following simple client-server interaction:

// Pseudo-code (client)
const result = server.addNumbers(2, 3);
console.log(result); // 5
// Behind the scenes (server)
function addNumbers(a, b) {
return a + b;
}

The magic is that the client doesn’t know the function actually lives on another server. The RPC layer serializes the function call, sends it over a transport (HTTP, TCP, or WebSocket), executes it remotely, and returns the response in a way that feels completely transparent.

Below is a diagram showing how it works in a system representation:

RPC frameworks are built around a few shared design principles:

• **Abstraction over HTTP **— Instead of thinking about endpoints, you think about function calls
• **Tight contracts **— Both sides agree on procedure names and parameter types
• **Serialization discipline **— Data is encoded and decoded consistently using formats such as JSON or Protobuf
• Transport Flexibility — RPCs can communicate over HTTP, WebSockets, or binary protocols
• Error Transparency — Exceptions that occur on the server appear as client-side errors

Together, these principles form the foundation of every RPC framework. However, different frameworks interpret them in unique ways depending on their goals and ecosystems.

Let’s look at how tRPC applies these ideas in a TypeScript-first environment in the next section and what makes it stand out from other RPC implementations.

Overview of tRPC

tRPC stands for Typescript Remote Procedure Call. It is a lightweight library that enables you to build end-to-end, typesafe APIs without requiring schemas or code generation. Instead of maintaining backend routes and frontend types separately, tRPC makes use of TypeScript’s inference system to keep both aligned. You can liken it to a bridge that keeps your client and server aware of each other’s types, ensuring that any mismatch is caught instantly before your code even runs.

At its core, tRPC is based on a simple concept: you write your server functions once and your client directly as if they were local. You start by defining your server’s procedures, which are the functions that handle queries or mutations. Instead of manually generating clients or schemas, tRPC automatically infers their types. The client then imports those types and calls the procedures just like normal functions, with full autocompletion and compile-time safety.

tRPC organizes APIs with routers and procedures. Think of a router as a folder that groups related procedures, and a procedure as the specific function in that folder that runs a query or a mutation. This structure keeps larger apps readable and encourages clear separation between features such as users, posts, or tasks.

Below is a typical demonstration:

const appRouter = router({
users: router({
getById: procedure,   // query
create: procedure,    // mutation
update: procedure,    // mutation
}),
posts: router({
list: procedure,      // query
create: procedure,    // mutation
}),
});

Under the hood, tRPC is grounded in a few familiar pieces. TypeScript provides the types that flow across the boundary. HTTP or WebSockets carry requests.Zod is commonly used to declare and validate inputs at runtime while also producing compile-time types. Framework adapters connect tRPC to servers such as Express, Next.js, or Fastify.

Features of tRPC

tRPC is built for developer speed and type safety. Here are some of the key features that make it stand out:

• **End-to-end type safety **— Both client and server share the same type definitions, catching errors during development instead of runtime
• **Autocompletion **— Your IDE always knows which procedures exist and what parameters they expect
• Zod integration — Input validation and type generation are combined in one place, ensuring your schema is always accurate
• Request batching — Multiple tRPC calls can be automatically combined into a single HTTP request to improve performance
• No code generation — Unlike GraphQL or gRPC, there’s no build step or generated SDK, as types flow naturally from your code
• Framework-agnostic — Works with React, Vue, Svelte, or vanilla JavaScript on the client and Express, Fastify, or Next.js on the server
• Middleware and context — Add authentication, logging, or permissions easily through typed context rather than boilerplate middleware
• Instant feedback loop — When you modify a server-side schema, your editor immediately highlights the affected client code

Limitations of tRPC

While tRPC offers development and type safety, there are some drawbacks to consider before implementing it in large-scale systems:

• TypeScript dependency — tRPC is only compatible with Typescript environments. If your backend and frontend are not written in Typescript, you lose Typescript’s primary benefits
• Not ideal for public APIs — tRPC is intended for internal APIs where a client and server share the same codebase. It doesn’t generate OpenAPI specs, making it less appropriate for external or third-party users
• Limited cross-language compatibility — Because tRPC relies on direct TypeScript inference, other languages (like Python, Go, or Java) can’t easily consume its endpoints
• Tight coupling between client and server — The automatic type sharing means any server-side change immediately affects the client. This is great for internal teams, but can slow down independent deployments in larger organizations
• Requires full-stack ownership — tRPC works best when the same team manages both sides of the stack. In setups with separate frontend and backend teams, versioning and coordination can become challenging

Build a tRPC app with React and Express

To see how tRPC works in practice, let’s build a small demo that includes both the backend and frontend in one project.

The project and its folders are already set up in the Github directory. Clone or download it. After downloading or cloning the project, open your terminal and set up the dependencies.

For the server, run:

cd server
npm install

In another terminal window, navigate to the client folder and run:

cd client
npm install

Once everything is installed, we’ll start wiring up both sides step by step to see how tRPC synchronizes types, validates input, and keeps the entire stack in sync automatically.

Initialize tRPC on the server

The first step is to set up the tRPC core and context that every request will use. Create a file called trpc.ts inside the server/src folder. Add the following code:

// server/src/trpc.ts
import { initTRPC } from '@trpc/server';
export const createContext = () => ({ userId: 'demo-user' });
export type Context = Awaited<ReturnType<typeof createContext>>;
const t = initTRPC.context<Context>().create();
export const router = t.router;
export const publicProcedure = t.procedure;
export const protectedProcedure = t.procedure.use(({ ctx, next }) => {
if (!ctx.userId) throw new Error('Not authenticated');
return next({ ctx });
});

We built the foundation that every tRPC application relies on. The initTRPC() function initializes the core engine that will register all our API routes later. The createContext() function returns a small object that travels with every request. In this demo, it simply contains a userId, but in a real application, it could include authentication data, a database instance, or environment configuration. You can think of this context as a small backpack that every request carries to your procedures. It ensures that shared data, such as user information, is always available wherever it is needed.

We also created two helpers: publicProcedure for routes that are open to everyone, and protectedProcedure for routes that require authentication. The protectedProcedure checks for a userId in the context and stops the request if it is missing.

With this setup, you have a simple, consistent way to handle authentication and access control across your entire API.

Define a router and validate inputs with Zod

Next, create a user router with input validation. Create a sub-folder called routes inside the server/routes folder. Inside it, create a file called users.ts. Add the following code:

// server/src/routers/users.ts
import { z } from 'zod';
import { router, publicProcedure, protectedProcedure } from '../trpc';
const users = [{ id: 1, name: 'Ada', email: '[email protected]' }];
export const userRouter = router({
list: publicProcedure.query(() => users),
createUser: protectedProcedure
.input(z.object({
name: z.string().min(1, 'Name cannot be empty'),
email: z.string().email('Invalid email address'),
}))
.mutation(async ({ input }) => {
const exists = users.some(u => u.email === input.email);
if (exists) throw new Error('Email already exists');
const user = { id: users.length + 1, ...input };
users.push(user);
return user;
}),
});

Here, we defined two procedures that the client can call. The first is the list procedure, which returns all the users in our temporary in-memory array. In a real application, this would likely be a database query that fetches user records.

The second procedure is the createUser procedure, which handles adding a new user, but before it accepts any input, it passes the data through a Zod schema. Zod acts as both a validator and a type generator. It checks at runtime that the data matches the expected format, and at the same time it gives the TypeScript compiler enough information to enforce those rules during development.

For example, the schema ensures that name is a non-empty string and email is a valid address. If any of these checks fail, the request never reaches the logic that saves the user.

Compose the main router and mount it in Express

Now you need to connect the router to an Express server. Create a file called index.ts inside the server/src folder and add the following code:

// server/src/index.ts
import express from 'express';
import cors from 'cors';
import { createExpressMiddleware } from '@trpc/server/adapters/express';
import { router, createContext } from './trpc';
import { userRouter } from './routers/users';
export const appRouter = router({ users: userRouter });
export type AppRouter = typeof appRouter;
const app = express();
app.use(cors());
app.use('/trpc', createExpressMiddleware({ router: appRouter, createContext }));
app.listen(3000, () => {
console.log('tRPC server running on http://localhost:3000/trpc');
});

We have now connected our router to an Express server so that it can start receiving and handling real API requests. The appRouter combines all the individual routers, like the one we created for users, into a single entry point that represents the entire backend API.

---

More great articles from LogRocket:

• Don’t miss a moment with The Replay, a curated newsletter from LogRocket
• Learn how LogRocket’s Galileo AI watches sessions for you and proactively surfaces the highest-impact things you should work on
• Use React’s useEffect to optimize your application’s performance
• Switch between multiple versions of Node
• Discover how to use the React children prop with TypeScript
• Explore creating a custom mouse cursor with CSS
• Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag

---

The createExpressMiddleware function does most of the heavy lifting. It automatically connects each procedure defined in your routers to an HTTP endpoint under /trpc. Whenever the client calls a procedure, this middleware determines which one to run and returns the response in the correct format.

We also exported the AppRouter type as it contains the complete definition of every query and mutation in your API. The frontend will import it next, which allows TypeScript to give the client full awareness of all the available procedures, their inputs, and their outputs.

With this setup, the server is now fully operational and ready to communicate with the frontend using strongly typed procedures rather than manually defined routes.

Create a typed client

Now that the server exposes a typed API, you need to connect the frontend by setting up the React client that speaks to tRPC server. Create a file called trpc.ts inside the client/src. Add the following code:

// client/src/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import type { AppRouter } from '../../server/src/index';
export const trpc = createTRPCReact<AppRouter>();

Note: In this monorepo setup, the client can import types directly from the server using a relative path. This works because both projects are in the same repository, and TypeScript can resolve types across folders. The AppRouter type contains the complete definition of your API, enabling full type safety across the client and server.

This file would act as a bridge between the client and the server.

To connect it with React Query, create a file called main.tsxin the client/src folder. Add the following code

// client/src/main.tsx
import React from 'react';
import ReactDOM from 'react-dom/client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { httpBatchLink } from '@trpc/client';
import App from './App';
import { trpc } from './trpc';
const queryClient = new QueryClient();
const trpcClient = trpc.createClient({
links: [httpBatchLink({ url: 'http://localhost:3000/trpc' })],
});
ReactDOM.createRoot(document.getElementById('root')!).render(
<trpc.Provider client={trpcClient} queryClient={queryClient}>
<QueryClientProvider client={queryClient}>
<App />
</QueryClientProvider>
</trpc.Provider>
);

In the code above, we connected this bridge to React Query, which handles caching and request management behind the scenes. The httpBatchLink function optimizes network usage by combining multiple procedure calls into a single HTTP request whenever possible.

This setup means we no longer need to manually define API endpoints or data-fetching hooks. Every function exposed by the server can now be called safely from the client, and TypeScript ensures that both sides stay perfectly in sync.

Build the UI and make typed calls

You need a simple form to list and add users. Create a file called App.tsx inside the client/src folder. Add the following code:

// client/src/App.tsx
import { useState } from 'react';
import { trpc } from './trpc';
export default function App() {
const [name, setName] = useState('Temi');
const [email, setEmail] = useState('[email protected]');
const users = trpc.users.list.useQuery();
const create = trpc.users.createUser.useMutation({
onSuccess: () => users.refetch(),
});
return (
<div style={{ padding: 20, fontFamily: 'Inter, sans-serif' }}>
<h2>tRPC Demo: Create User</h2>
<h3>Existing users</h3>
<ul>
{users.data?.map(u => (
<li key={u.id}>{u.name} — {u.email}</li>
))}
</ul>
<h3>Create user</h3>
<div style={{ display: 'flex', gap: 8, marginBottom: 8 }}>
<input value={name} onChange={e => setName(e.target.value)} placeholder="Name" />
<input value={email} onChange={e => setEmail(e.target.value)} placeholder="Email" />
<button onClick={() => create.mutate({ name, email })}>Create</button>
</div>
{create.isPending && <p>Creating...</p>}
{create.error && <p style={{ color: 'crimson' }}>{create.error.message}</p>}
</div>
);
}

We’ve just created a simple but fully functional interface that communicates directly with the backend. The users.list query fetches data from the server and automatically updates when the data changes. The useQuery() hook from React Query manages caching and synchronization, ensuring the user list always stays current without extra setup.

The createUser mutation calls the users.createUser procedure on the server and sends the input data. Because the procedure uses a Zod schema, any invalid input, such as an empty name or an incorrectly formatted email, is immediately rejected before it affects the data store.

There are no manual API calls or endpoint configurations here. RPC handles all the communication behind the scenes, while TypeScript provides autocompletion and compile-time checking for every parameter and return value. When the mutation succeeds, the list refetches automatically, keeping the UI responsive and consistent.

With this UI in place, you can already fetch data, add new records, and see how tRPC keeps both the client and server perfectly aligned through shared types and real-time validation.

Now let’s test tRPC’s type safety by breaking things on purpose. In the client/app.tsx, change:

<button onClick={() => create.mutate({ name, email })}>Create</button>

To:

<button onClick={() => create.mutate({ name: 'Ada', email: 42 })}>Create</button>

You’ll see that typescripts automatically flags it, and you’ll see a red underline. When you hover over it, you’ll see:

The expected type comes from property 'email' which is declared here on type '{ name: string; email: string; }'

This shows tRPC’s end-to-end type safety. The client knows exactly what the server expects, and invalid data is caught instantly at compile time, long before it can make a request.

Undo that and let’s try to change the server schema and watch the client respond. Modify the input schema in server/src/routers/users.ts:

.input(z.object({
name: z.string().min(1),
email: z.string().email(),
role: z.enum(['user', 'admin']),
}))

When you go back to the client folder in your app.tsx, you should see a red underline on this line:

create.mutate({ name, email });

When you hover on it, you’ll see:

Argument of type '{ name: string; email: string; }' is not assignable to parameter of type '{ name: string; email: string; role: "user" | "admin"; }'.
Property 'role' is missing in type '{ name: string; email: string; }' but required in type '{ name: string; email: string; role: "user" | "admin"; }'.

This is tRPC’s schema synchronization in action. The frontend and backend share a single type contract, so when you change the schema on the server, the client automatically updates its expectations. There is no need for code generation or manual syncing because everything stays aligned by design.

You can fix it by changing the code to:

create.mutate({ name: 'Temi', email: '[email protected]', role: 'user' });

Now let’s test everything together. Make sure both your development servers are running.

In the server terminal, run:

npm run dev

You should see a message like:

tRPC server running on[ http://localhost:3000/trpc](http://localhost:3000/trpc)

Also in the client terminal, run:

npm run dev

When you open that URL, you’ll see the tRPC Demo page showing the existing user. Try adding a new user. The entry should appear instantly under the list. If you enter an invalid email, the client displays a clear validation message.

Everything you just saw, from instant validation to automatic type updates and communication between the client and server, happens because both ends of the application share the same source of truth for types and data contracts.

Let’s now explore oRPC and how it approaches the same idea of remote procedure calls through a more language-agnostic and interoperable design.

Overview of oRPC

oRPC stands for Open Remote Procedure Call. You can think of it as tRPC’s younger sibling. It provides the same type safety and developer experience but adds full OpenAPI support and a stronger focus on interoperability.

Like tRPC, oRPC lets you build type-safe APIs where the client can call server functions directly as if they were local. But it goes a step further by automatically generating OpenAPI specifications from your procedures. This means your API is not only type-safe within TypeScript but also fully documented and compatible with other clients or services through standard API specifications.

You can liken oRPC to a bridge that connects the simplicity of RPC-based development with the openness of the API ecosystem. It gives you the flexibility to keep your TypeScript workflow while making your API discoverable and usable by tools like Swagger, Scalar, or Postman without extra setup.

Like tRPC, oRPC uses this router–procedure structure to keep APIs modular and maintainable. The key difference is that oRPC automatically produces a schema contract (based on the OpenAPI specification) that other languages, tools, and frameworks can understand, allowing your type-safe API to integrate seamlessly with non-TypeScript environments.

Here’s a simple demonstration:

// Router structure example
const appRouter = orpc.router({
users: orpc.router({
getById: orpc.procedure,   // query
create: orpc.procedure,    // mutation
update: orpc.procedure,    // mutation
}),
posts: orpc.router({
list: orpc.procedure,      // query
create: orpc.procedure,    // mutation
}),
});

Under the hood, oRPC builds on familiar components, one of which is Zod, which is used to declare and validate input schemas while providing runtime and compile-time safety.

However, oRPC does not limit you to only Zod. It also supports other schema libraries such as Valibot, ArkType, or any validator that can produce a compatible JSON Schema. This flexibility means you can use your preferred validation library and still get type safety and OpenAPI support automatically.

Features of oRPC

oRPC extends on tRPC’s simplicity but with built-in Open API support, typed error handling, and schema flexibility. Below are some of the features of oRPC:

1. OpenAPI support

The “o” in oRPC refers to its built-in OpenAPI generation. Every procedure produces a full, compliant spec, so your API can be used from any language or tool that understands OpenAPI. You can plug that spec into tools like Scalar or Swagger to get interactive docs and an easy testing surface.

2. First-contract approach

oRPC is a contract-first workflow. You define the API structure before proceeding to code implementation. This type of workflow minimizes schema mismatches and maintains alignment between frontend and backend teams.

3. Typed error handling

oRPC biasts of a dedicated ORPCError class used for creating strongly typed errors. With it, you can define custom errors with the error.find method. This ensures that you have consistent responses and cleaner debugging.

4. Schema flexibility

oRPC is not tied to a single validation library. It works with Zod, Valibot, ArkType, or any tool that can produce a JSON schema. This gives you the freedom to choose your preferred validation system while maintaining type inference and Open API compatibility.

5. Batching, limiting, and retrying

oRPC comes with built-in features that can help in batching multiple requests, limiting API calls, and retrying failed requests. These capabilities make it suitable for high-traffic or distributed environments.

6. Type safety and autocompletion

Like tRPC, oRPC provides end-to-end type safety. When you change a schema on the server, the client instantly updates to reflect it, preventing invalid calls before runtime.

7. Cross-framework compatibility

Because it generates OpenAPI specs, oRPC works with frameworks and languages outside TypeScript, such as Python, Go, or Java, making it ideal for polyglot teams.

Limitations of oRPC

Despite its flexibility and OpenAPI support, oRPC has a few trade-offs to keep in mind:

• TypeScript dependency — oRPC is built around TypeScript inference. Teams using plain JavaScript or other languages won’t benefit from its type-safe contracts
• Extra complexity for small projects — For smaller or internal-only applications, the added OpenAPI layer can be unnecessary overhead compared to a simpler setup like tRPC
• Less suited for polyglot microservices — Although oRPC generates OpenAPI specs, it’s still primarily optimized for TypeScript-based stacks. Large, multi-language systems might prefer gRPC or REST for cross-language communication
• Contract-first workflow required — oRPC emphasizes defining API contracts before implementation. Teams that prefer code-first workflows may find this approach restrictive

Build an oRPC app

To see how oRPC works in practice, let’s build a small demo that includes both the backend and frontend in one project.

The project and its folders are already set up in the Github directory. Clone or download it. After downloading or cloning the project, open your terminal and set up the dependencies.

For the server, run:

cd server
npm install

In another terminal window, navigate to the client folder and run:

cd client
npm install

Once everything is installed, we’ll start wiring up both sides step by step to see how tRPC synchronizes types, validates input, and keeps the entire stack in sync automatically.

Initialize oRPC on the server

We’ll start by setting up the oRPC core and router that every request will use. Create a file called orpc.ts inside the server/src folder. Add the following code:

// server/src/orpc.ts
import type { IncomingHttpHeaders } from "node:http";
import { os, ORPCError } from "@orpc/server";

export type BaseContext = { headers: IncomingHttpHeaders };

export { os, ORPCError };

This file sets up a simple base context that carries request headers through every call.

In oRPC, procedures and routers are built around this context, allowing access to things like authentication, tokens, or custom headers.

Define a router and validate inputs with Zod

Next, you need a user router with Zod validation. Create a file called users.ts inside the server/src folder. Add the following code:

// server/src/routers/users.ts
import * as z from "zod";
import { os, ORPCError } from "@orpc/server";

const users = [{ id: 1, name: "Ada", email: "[email protected]" }];

const UserSchema = z.object({
id: z.number().int().min(1),
name: z.string(),
email: z.string().email(),
});

const CreateUserInput = z.object({
name: z.string().min(1, "Name cannot be empty"),
email: z.string().email("Invalid email address"),
});

export const userRouter = {
list: os
.route({ method: "GET", path: "/users" })
.output(z.array(UserSchema))
.handler(async () => users),

create: os
.route({ method: "POST", path: "/users" })
.input(CreateUserInput)
.output(UserSchema)
.handler(async ({ input }) => {
if (users.some((u) => u.email === input.email)) {
throw new ORPCError("CONFLICT", { message: "Email already exists" });
}
const user = { id: users.length + 1, ...input };
users.push(user);
return user;
}),
};

In the code above, we define two endpoints. The first is a list that returns the full user array, and the second is create, which validates and adds a new user. Both are fully typed, so if you send bad input, the server rejects it automatically through Zod validation.

Compose the main router and mount it in Express

Now, bring everything together by combining the user router, oRPC runtime, and OpenAPI layer inside a single Express server. Create a file called index.ts inside the server/src folder. Add the folloiwng code:

// server/src/index.ts
import express from "express";
import cors from "cors";

// oRPC runtimes
import { RPCHandler } from "@orpc/server/node";
import { OpenAPIHandler } from "@orpc/openapi/node";
import { OpenAPIGenerator } from "@orpc/openapi";
import { ZodSmartCoercionPlugin, ZodToJsonSchemaConverter } from "@orpc/zod";

import { userRouter } from "./routers/users";

export const appRouter = { users: userRouter };
export type AppRouter = typeof appRouter;

const app = express();
app.use(cors());
app.use(express.json());

/** RPC endpoints at /rpc (used by your React client) */
const rpc = new RPCHandler(appRouter);
app.use("/rpc", async (req, res, next) => {
const { matched } = await rpc.handle(req, res, {
prefix: "/rpc",
context: { headers: req.headers },
});
if (matched) return;
next();
});

/** OpenAPI REST endpoints at /api (used by Swagger UI "Try it out") */
const openapi = new OpenAPIHandler(appRouter, {
plugins: [new ZodSmartCoercionPlugin()],
});
app.use("/api", async (req, res, next) => {
const { matched } = await openapi.handle(req, res, {
prefix: "/api",
context: { headers: req.headers },
});
if (matched) return;
next();
});

/** OpenAPI JSON and docs */
const generator = new OpenAPIGenerator({
schemaConverters: [new ZodToJsonSchemaConverter()],
});

app.get("/openapi.json", async (_req, res) => {
const spec = await generator.generate(appRouter, {
info: { title: "Users API", version: "1.0.0" },
servers: [{ url: "http://localhost:4000/api" }],
});
res.type("application/json").send(spec);
});

app.get("/docs", (_req, res) => {
res.type("html").send(`<!doctype html>
<html>
<head>
<meta charset="utf-8"/>
<title>Users API Docs</title>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<link rel="stylesheet" href="https://unpkg.com/swagger-ui-dist/swagger-ui.css"/>
</head>
<body>
<div id="swagger-ui"></div>
<script src="https://unpkg.com/swagger-ui-dist/swagger-ui-bundle.js"></script>
<script>
window.onload = function () {
window.ui = SwaggerUIBundle({
url: "/openapi.json",
dom_id: "#swagger-ui",
presets: [SwaggerUIBundle.presets.apis],
layout: "BaseLayout",
});
};
</script>
</body>
</html>`);
});

const port = 4000;
app.listen(port, () => {
console.log(`oRPC server listening on http://localhost:${port}`);
});

Unlike tRPC, which only provides typed procedures through TypeScript clients, oRPC exposes your API as both an RPC interface and a REST-compliant OpenAPI service, all within the same code.

Create the typed client

Now we’ll set up the frontend. Create a file called orpc.ts inside the client/src. Add the following:

import type { RouterClient } from "@orpc/server";
import { createORPCClient } from "@orpc/client";
import { RPCLink } from "@orpc/client/fetch";
import type { AppRouter } from "@server/index"; // this is your router type

const link = new RPCLink({
url: "http://localhost:4000/rpc", // Add /rpc here
});

export const orpc: RouterClient<AppRouter> = createORPCClient(link);

This gives the client full type awareness of the backend’s procedures, just like tRPC, but with OpenAPI compliance.

Also, create a file called main.tsc in the client/src folder. Add the following code:

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";

ReactDOM.createRoot(document.getElementById("root")!).render(<App />);

This will wire everything up.

To use the oRPC client to list and create users, create a file called App.tsx in the client/src folder, add the following code:

import { useEffect, useState } from "react";
import { orpc } from "./orpc";

type User = { id: number; name: string; email: string };

export default function App() {
const [users, setUsers] = useState<User[]>([]);
const [name, setName] = useState("Temi");
const [email, setEmail] = useState("[email protected]");
const [error, setError] = useState<string | null>(null);
const [busy, setBusy] = useState(false);

// Load users once
useEffect(() => {
orpc.users
.list()
.then(setUsers)
.catch((e) => setError(String(e)));
}, []);

async function onCreate() {
setBusy(true);
setError(null);
try {
const user = await orpc.users.create({ name, email });
setUsers((prev) => [...prev, user]);
setName("");
setEmail("");
} catch (e: any) {
setError(e?.message ?? "Request failed");
} finally {
setBusy(false);
}
}

return (
<div style={{ padding: 20, fontFamily: "Inter, system-ui, sans-serif" }}>
<h2>oRPC Demo: Create User</h2>

<h3>Existing users</h3>
<ul>
{users.map((u) => (
<li key={u.id}>
{u.name} — {u.email}
</li>
))}
</ul>

<h3>Create user</h3>
<div style={{ display: "flex", gap: 8, marginBottom: 8 }}>
<input
value={name}
onChange={(e) => setName(e.target.value)}
placeholder="Name"
/>
<input
value={email}
onChange={(e) => setEmail(e.target.value)}
placeholder="Email"
/>
<button onClick={onCreate} disabled={busy}>
{busy ? "Creating..." : "Create"}
</button>
</div>

{error && <p style={{ color: "crimson" }}>{error}</p>}
</div>
);
}

Now, before we run it, let’s test oRPC’s end-to-end type safety just like we did for tRPC by breaking things on purpose.

In client/src/App.tsx, find this line:

await orpc.users.create({ name, email });

Change it to:

await orpc.users.create({ name: 'Ada', email: 42 });

You’ll immediately see a red underline under 42. When you hover over it, TypeScript tells you:

The expected type comes from property 'email' which is declared here on type '{ name: string; email: string; }'

This shows oRPC’s compile-time type safety in action. The client knows exactly what the server expects because both sides share the same schema through AppRouter. Invalid data is caught instantly before any network request is made.

Undo that change before moving on.

Now let’s test what happens when we change the schema on the server. Open server/src/routers/users.ts and modify the CreateUserInput schema by adding a role field:

const CreateUserInput = z.object({
name: z.string().min(1, "Name cannot be empty"),
email: z.string().email("Invalid email address"),
role: z.enum(['user', 'admin']),
});

When you switch back to the client’s App.tsx, TypeScript will immediately highlight an error on this line:

await orpc.users.create({ name, email });

Hover over it and you’ll see:

Argument of type '{ name: string; email: string; }' is not assignable to parameter of type '{ name: string; email: string; role: "user" | "admin"; }'.
Property 'role' is missing in type '{ name: string; email: string; }' but required in type '{ name: string; email: string; role: "user" | "admin"; }'.

That’s oRPC’s schema synchronization at work. The frontend and backend share a single type contract. As soon as the server’s schema changes, the client updates its expectations automatically, eliminating the need for code generation, manual syncing, and guessing what the API looks like.

If you change that line to:

await orpc.users.create({
name: 'Temi',
email: '[email protected]',
role: 'user',
});

Your TypeScript becomes happy again.

Undo the changes back to the original, and then save and start up the server in the server terminal.

npm run dev

Also in the client terminal, run:

npm run dev

Your client will launch at http://localhost:5173

You can test it out by adding a new user, like you did for tRPC. The entry should appear instantly under the list.

RPC and REST in Sync

Unlike tRPC, oRPC also generates OpenAPI documentation automatically.

This means your same endpoints are instantly available as REST APIs, complete with interactive docs.

Open your browser and visit:

• http://localhost:4000/docs to VIEW the swagger UI
• http://localhost:4000/openapi.json to view the raw OpenAPI schema

Here, you can use the “Try it out” section to make requests directly to /api/users endpoints without writing any client code.

tRPC vs oRPC

While tRPC and oRPC share the same foundation of end-to-end type safety, their internal architectures, tooling, and developer ergonomics set them apart. Below are the core differences based on hands-on testing and developer experience.

Request handling and throughput

• tRPC is designed for simplicity and raw speed. It uses lightweight JSON-RPC-like calls over HTTP, which makes it ideal for high-frequency client-server communication. In practice, it handles around 2–3k requests per second on a single Node.js process, and its batching support helps minimize round trips
• oRPC, on the other hand, matches tRPC’s performance but goes further. Its dual-handler architecture (RPCHandler and OpenAPIHandler) lets it serve both RPC and REST requests through the same Express instance. That means you can power internal TypeScript clients and external REST consumers from a single router, without duplicating routes or validation logic

Schema generation and API support

• tRPC keeps everything inside TypeScript but doesn’t generate external API schemas by default. To get REST or OpenAPI support, you need a plugin like trpc-openapi, which adds extra setup and mapping work

• oRPC takes a different approach; every procedure can automatically expose a full OpenAPI 3.1 spec and interactive documentation through Swagger or Scalar. Your validation schemas double as API contracts, so you get REST endpoints, live docs, and schema exports with no extra tooling

Type safety and synchronization

• In tRPC, type safety flows directly from server to client. Every procedure is strongly typed, and invalid inputs are caught immediately in your editor. However, this safety only applies inside TypeScript; external clients don’t automatically share those guarantees
• oRPC extends type safety beyond TypeScript. At compile time, TypeScript clients get full inference just like tRPC. At runtime, Zod validates every incoming request to ensure the data matches the schema. And at the contract level, the generated OpenAPI spec enforces those same rules for non-TypeScript clients

Code-first pattern vs contract-first design

• tRPC uses a code-first pattern exclusively. In it, you write procedures, and TypeScript infers all input/output types automatically. This makes it perfect for small teams and fast-moving fullstack apps where the same developers manage both ends
• oRPC supports both code-first and contract-first workflows. In contract-first design, you define routes and schemas (the “contract”) before implementing the logic. This is ideal for larger teams where backend, frontend, and QA work in parallel. This flexibility allows you to scale from prototype to production-grade service without changing tools

Error handling

• tRPC relies on standard JavaScript errors or custom ones you define in your procedures. While this works fine in a TypeScript-only setup, it doesn’t automatically standardize how those errors appear to other clients
• oRPC, on the other hand, has a structured error mechanism called ORPCError designed to work easily with OpenAPI. This means every error type is automatically described in your API specification

When to choose tRPC or oRPC?

tRPC is usually the best fit when your entire application is TypeScript-based and managed by a single team. It provides the fastest developer feedback loop, minimal tooling, and a seamless experience for building internal APIs. If your backend and frontend live in the same repo, tRPC keeps everything tightly aligned and extremely productive.

oRPC becomes a stronger choice when your API needs to serve more than just TypeScript clients. If you work with external partners, mobile teams, Python or Go services, or you need auto-generated documentation, oRPC’s built-in OpenAPI layer gives you a cleaner, more interoperable contract. You also get both RPC and REST interfaces from the same procedures, which is ideal when your system needs to grow beyond a single stack.

Scenario	tRPC	oRPC	Recommended
Your entire stack is TypeScript and managed by one team	✅	❌	tRPC
You need automatic OpenAPI docs, schema exports, or SDK generation	❌	✅	oRPC
You expect mobile apps, Python/Go services, or external partners to consume API	❌	✅	oRPC
You want the simplest setup with minimal tooling	✅	❌	tRPC
You may someday expose your internal API as REST	❌	✅	oRPC
You prefer contract-first design for cross-team coordination	❌	✅	oRPC
You are building a prototype that may scale into a public API	❌	✅	oRPC
You want maximum IDE autocompletion and instant type inference	✅	✅	Both

Conclusion

tRPC and oRPC solve the same problem, but they approach it from different angles. tRPC keeps things simple and fast for teams that live fully in the TypeScript ecosystem. It offers a smooth workflow, instant type feedback, and a structure that works well for internal apps or monorepos where both sides of the stack move together.

oRPC steps in when your API needs to reach beyond TypeScript. The OpenAPI support, typed errors, and stronger contract model make it a good fit for teams that expect to work with external services, mobile apps, or multiple languages. It also lets you expose both RPC and REST from the same routes, which is useful once a project grows and serves a wider audience.

The choice depends on your environment. If you want the fastest path to building a fully typed internal API, tRPC is hard to beat. If your project calls for a shared contract that works across tools, platforms, and languages, oRPC offers the structure that keeps everything aligned. Both are solid options, and the best one is simply the one that fits the shape of your system and your team.

LogRocket understands everything users do in your web and mobile apps.

LogRocket lets you replay user sessions, eliminating guesswork by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks, and with plugins to log additional context from Redux, Vuex, and @ngrx/store.

With Galileo AI, you can instantly identify and explain user struggles with automated monitoring of your entire product experience.

Modernize how you understand your web and mobile apps — start monitoring for free.