oRPC: A TypeScript Contract Layer That Puts OpenAPI Coercion in the Middle

The Problem oRPC Solves: Contract Drift Between Server and Client

Most TypeScript API projects start with a server, then hand-write a client or generate one from OpenAPI. The server schema and the client types drift apart. oRPC attacks that by defining an API contract as the single source of truth. The @orpc/contract package holds that definition. @orpc/server implements it, and @orpc/client consumes it with full type inference. If you change a contract field, the client type updates immediately. That is the core value. It is aimed at teams building APIs where the client and server live in the same repository or at least share a TypeScript monorepo. It is less useful if your clients are not TypeScript or if you must serve many external consumers.

How the Contract Flows Through the Packages

The contract is not just a type definition. It is a runtime object that carries validation logic. You define a procedure with an input schema, an output schema, and a handler. The server package interprets that contract and exposes it over HTTP. The client package creates a typed caller from the same contract. No code generation step appears in the README; the types flow directly from the contract object. That is the key mechanism. The @orpc/openapi package adds OpenAPI compatibility, which means you can generate documentation or feed the contract into OpenAPI tooling. The @orpc/json-schema package handles what the description calls smart coercion for OpenAPI requests. That suggests it converts incoming OpenAPI request data into the types your schema expects, though the README gives no details on how that coercion behaves. The design is modular: every feature is a separate npm package, from @orpc/zod to @orpc/cloudflare.

Getting Started: Install the Packages You Actually Need

There is no single install command in the README, but the package list implies the workflow. You install @orpc/contract, @orpc/server, and @orpc/client for the base setup. Then you add a schema integration, like @orpc/zod, @orpc/valibot, or @orpc/arktype. The README does not show a code example, so exact configuration keys are not available here. However, the pattern is clear: you define a contract with a schema library, implement it on the server, and call it from the client. For framework support, you add @orpc/next for Next.js Server Functions, @orpc/nest for NestJS, or @orpc/node for plain Node.js. The @orpc/openapi package is optional unless you need OpenAPI output. The beta versions, such as v2.0.0-beta.31, are published to npm under the @orpc scope. You can install them with npm install @orpc/client@beta or the equivalent for each package.

The Schema Library Choice: Zod, Valibot, or ArkType

oRPC does not force one validator. It has separate integration packages for Zod, Valibot, and ArkType. That is a strength if you already use one of those. It is also a maintenance burden for the project, because each integration must track upstream changes. The README lists all three as equals, so you can pick based on your existing stack. Zod is the most common, but Valibot offers a smaller footprint and ArkType focuses on performance. If you are starting fresh, the choice matters because it affects every contract you write. The @orpc/experimental-effect package suggests even more schema flexibility for Effect users, but it is marked experimental. That label is a warning: the API may change. For production, stick with the non-experimental integrations.

Where oRPC Struggles: Beta Status and Package Sprawl

The most obvious limitation is the version number. v2.0.0-beta.31 means the project is still in beta. The release dates are close together, with three releases in four days, which shows active development but also implies instability. The README does not promise API stability. If you adopt oRPC, you must budget for breaking changes. The second issue is package sprawl. The README lists over twenty packages. That gives flexibility, but it also means you must learn which packages you need and track updates across many dependencies. The @orpc/experimental-msw and @orpc/experimental-effect packages are explicitly experimental, so they are not safe for production. The @orpc/hibernation package depends on platform-specific APIs like Cloudflare's Hibernation WebSocket, which only work on certain runtimes. If you are on a standard Node.js server, that package is irrelevant.

Alternatives: tRPC and Plain OpenAPI Generation

The most direct alternative is tRPC, which also provides end-to-end type safety. The difference is that tRPC is tightly coupled to its own client and server, and it does not naturally produce OpenAPI documents. oRPC has a separate @orpc/openapi package, and the @orpc/trpc package lets you reuse existing tRPC routers inside oRPC. That is a bridge, not a replacement. Another alternative is to skip the framework entirely and use OpenAPI as the source of truth, generating types with tools like openapi-typescript. That approach works for any client language, but it requires a code generation step and does not give you type inference from a server implementation. oRPC inverts that: the TypeScript contract is the source, and OpenAPI is an output. If you need OpenAPI as the canonical artifact, oRPC is the wrong tool.

Maintenance, Licensing, and the Cost of Upgrades

The project is MIT licensed, so you can use it commercially without paying for a license. The README mentions GitHub Sponsors and Open Collective, which means the project relies on community funding. There is no mention of a commercial support contract. Maintenance cost is real: with over twenty packages, every release requires updating several dependencies. The beta cadence means you should pin exact versions and review changelogs before upgrading. The @orpc/opentelemetry and @orpc/pino packages indicate the project takes observability seriously, which helps in production, but they are extra packages to maintain. The README does not provide a migration guide between beta versions. You should assume that upgrading from one beta to the next may require code changes.

Editorial conclusion

Adopt oRPC if you want a single TypeScript contract that drives both server and client with end-to-end type safety, and if you are comfortable with a v2.0.0-beta release cycle. Do not adopt it if you need a stable, long-term API or if you dislike managing many small packages. Before committing, verify that the specific integrations you need (Next.js, NestJS, Cloudflare, or the schema library of your choice) are maintained and that the beta API matches your use case, since breaking changes are still possible.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes