tRPC vs gRPC vs oRPC — Choosing the Right RPC Style for Your Project

tRPC, gRPC, and oRPC are all ways to build Remote Procedure Call (RPC) style APIs but target different priorities: gRPC focuses on high-performance, language‑agnostic, binary RPC for microservices and systems programming; tRPC focuses on developer ergonomics and end‑to‑end TypeScript type safety for full‑stack TypeScript apps; oRPC sits between them by adding OpenAPI/REST interoperability and richer tooling while keeping TypeScript-first ergonomics.【5】【1】【2】

Essential context and comparison

What each project is and its core goals

gRPC — a mature, language‑agnostic RPC framework from Google that uses HTTP/2 transport and Protocol Buffers (protobufs) for compact binary serialization and an IDL-driven contract between services【5】【1】.
tRPC — a TypeScript‑first RPC library that exposes server procedures directly to TypeScript clients, delivering zero‑boilerplate end‑to‑end type safety and rapid developer iteration (especially inside monorepos and Next.js apps)【1】【3】.
oRPC — an evolution of the TypeScript‑first RPC idea that preserves tRPC‑style type safety but adds built‑in OpenAPI generation and optional REST endpoints so APIs are language‑agnostic and easier for external consumers to adopt【2】.

Technical differences (transport, IDL, typing, languages)

Transport and serialization:
- gRPC uses HTTP/2 and binary protobuf serialization, giving multiplexing, low overhead, and streaming semantics (client, server, bidirectional)【1】【5】.
- tRPC typically runs over HTTP/1.1 or WebSocket using JSON (or JSON-like payloads) and depends on the HTTP framework in use (Next.js, Express, etc.)【1】【3】.
- oRPC commonly exposes RPC endpoints but also generates OpenAPI which can be served as JSON/HTTP REST—transport depends on implementation and hosting, but it prioritizes interoperable JSON/HTTP for external clients【2】.
Interface definition and typing:
- gRPC: explicit IDL via .proto files (Protocol Buffers). Strongly typed across languages, code‑generation required for clients and servers【1】【5】.
- tRPC: no separate IDL—types flow from server code to TypeScript clients via compile‑time inference (no protobufs, no generated clients)【1】【3】.
- oRPC: retains TypeScript‑first typing but generates OpenAPI (a machine‑readable contract) so other languages/tools can consume your API【2】.
Language ecosystem:
- gRPC supports many languages (Go, Java, Python, C++, Node, etc.) because of its protobuf IDL and codegen【5】.
- tRPC and oRPC are TypeScript/JavaScript centric; oRPC bridges the gap for non‑TypeScript consumers by exporting OpenAPI specs【2】【1】.
Streaming and advanced RPC features:
- gRPC supports streaming natively and is designed for streaming and low-latency interservice communication【1】【5】.
- tRPC mainly targets request/response and real‑time via WebSockets or libraries layered on top; it’s not a drop‑in for gRPC streaming semantics【1】.
- oRPC focuses on interoperability and type safety rather than replacing streaming semantics; streaming support depends on the specific implementation choices【2】.

When to choose each (practical guidance)

Choose gRPC when:
- You need high throughput, low latency, and efficient binary payloads (microservices, mobile backends, streaming systems)【1】【5】.
- Your system involves multiple languages and you require a language‑neutral contract and code generation【5】.
- You rely on native streaming, advanced flow control, or built‑in health checks/load balancing features【1】【5】.
Choose tRPC when:
- Your stack is predominantly TypeScript (both client and server) and you want end‑to‑end type safety with minimal boilerplate【1】【3】.
- Rapid iteration, developer DX, and tight integration (e.g., Next.js, monorepos) are higher priority than cross‑language interoperability【1】【3】.
- You want simple RPC semantics without defining .proto files or generating code.
Choose oRPC when:
- You want tRPC‑like developer ergonomics but also need to provide an OpenAPI/REST surface for external teams, mobile clients, or other languages【2】.
- Interoperability and auto‑generated docs/specs are required without abandoning a TypeScript‑first workflow【2】.

Tradeoffs, pitfalls and operational considerations

Performance vs ergonomics:
- gRPC’s binary protobufs and HTTP/2 give better raw performance than JSON-over-HTTP approaches, but require more setup and tooling (codegen, .proto management)【1】【5】.
- tRPC is ergonomically superior for TypeScript teams but can’t easily serve non‑TypeScript consumers and may be less performant for high‑scale interservice traffic【1】【3】.
Versioning and schema evolution:
- gRPC/protobuf encourage explicit schema versioning and are well suited for controlled evolution across services and languages【1】.
- tRPC’s implicit schema (types in code) makes evolution easy inside a single stack but can be awkward if you need strict backwards compatibility guarantees for external clients【3】.
- oRPC’s OpenAPI output helps with versioning and external compatibility because external consumers can rely on a standard contract【2】.
Debugging and observability:
- Protobuf/gRPC payloads are binary which can make debugging slightly harder without tools; however, strong IDL and client stubs reduce certain classes of runtime errors【1】【5】.
- JSON/TypeScript stacks (tRPC/oRPC) are easy to inspect and debug in browser devtools and logging systems【1】【2】.
Browser support:
- gRPC in browsers requires gRPC-Web or proxies because full HTTP/2 streaming and some transports aren’t directly usable from browsers; this adds infra complexity【1】【6】.
- tRPC and oRPC (via OpenAPI/JSON) are straightforward to use from browsers【1】【2】.
External adoption:
- If your API must be consumed by multi-language partners, public clients, or non‑JavaScript ecosystems, gRPC or oRPC (via OpenAPI) are better choices than tRPC alone【2】【5】.

Developer experience and ergonomics

Rapid iteration: tRPC wins for fast feedback loops and zero client codegen. You change a server type and the TypeScript client reflects it immediately【1】【3】.
Discoverability & docs: oRPC’s automatic OpenAPI yields standard interactive docs (Swagger/Redoc) that external teams can use; gRPC can produce documentation but typically requires separate tooling; tRPC lacks a standardized OpenAPI output by default【2】【1】.
Error handling and typed errors:
- tRPC and oRPC provide idiomatic TypeScript error handling patterns; oRPC documents error shapes via OpenAPI which helps cross‑language consumers【2】.
- gRPC has a well‑established status code model and structured errors (grpc-status, grpc-message), but mapping them to client semantics requires discipline【1】.

Example usage scenarios (short)

Microservices across languages with heavy streaming: gRPC (Protobufs + HTTP/2)【5】.
Full‑stack React + Next.js app with shared types and rapid feature iteration: tRPC【1】【3】.
TypeScript backend needing to serve TypeScript clients plus third‑party teams/mobile apps: oRPC (TypeScript + OpenAPI)【2】.

Small code sketches (illustrative)

tRPC (server-side router example, TypeScript)

// server.ts (tRPC)
import { initTRPC } from '@trpc/server';
const t = initTRPC.create();
export const appRouter = t.router({
  getUser: t.procedure.input(z.object({ id: z.string() })).query(({ input }) => {
    return db.user.findUnique({ where: { id: input.id } });
  }),
});
export type AppRouter = typeof appRouter;

Note: tRPC exposes types to the client directly at compile time; no .proto or codegen step is needed【1】【3】.

gRPC (proto skeleton)

// user.proto
syntax = "proto3";
package user;
service UserService {
  rpc GetUser(GetUserRequest) returns (UserResponse);
}
message GetUserRequest {
  string id = 1;
}
message UserResponse {
  string id = 1;
  string name = 2;
}

Note: From this .proto you generate server and client stubs in many languages; transport and streaming are handled by gRPC over HTTP/2【1】【5】.

oRPC (conceptual): server procedures defined in TypeScript, plus OpenAPI generated automatically; usage patterns are similar to tRPC but produce a standard OpenAPI spec consumable outside TypeScript【2】.

Choosing among them — checklist

Is your ecosystem multi‑language and do you need language‑neutral contracts? If yes → prefer gRPC (or oRPC with OpenAPI)【5】【2】.
Do you want zero client codegen, TypeScript end‑to‑end type safety, and fast dev DX? If yes → prefer tRPC【1】【3】.
Do you need TypeScript ergonomics but also public/third‑party clients and auto docs? If yes → prefer oRPC【2】.
Do you need native streaming, low latency, and binary efficiency? If yes → gRPC is the stronger fit【1】【5】.
Will most clients be browsers or mobile apps expecting JSON/HTTP? If yes → tRPC or oRPC (OpenAPI/REST) are easier to adopt【2】【1】.

Limitations of sources and open questions

Many community comparisons emphasize DX and high‑level tradeoffs but concrete latency/throughput numbers depend on workload, deployment, and whether you use gRPC-Web, HTTP/2 tuning, or JSON over HTTP2. Benchmarks should be run for production workloads before making final decisions【1】【5】.
oRPC is a newer approach in this space; implementations and ecosystem maturity vary—evaluate the specific oRPC project (plugins, OpenAPI fidelity, performance) before committing【2】.

Conclusion Pick based on constraints: use gRPC for high‑performance, multi‑language microservices and streaming; use tRPC for best-in-class TypeScript developer experience inside a TypeScript-centered stack; use oRPC when you want TypeScript ergonomics plus a standards‑based OpenAPI surface for cross‑language interoperability【5】【1】【2】.

What each project is and its core goals#

Technical differences (transport, IDL, typing, languages)#

What each project is and its core goals

Technical differences (transport, IDL, typing, languages)