I've been using ts-rest for a while, and I genuinely liked it.
Contract-first APIs, end-to-end type safety, OpenAPI support, and a clean developer experience. It had pretty much everything I needed.
But over time, I started having concerns about its maintenance. Development seemed to slow down, updates became less frequent, and I was looking for better Zod 4 support.
It was still a good library, but I didn't want to start my next project with something I was already uncertain about.
So I started looking for alternatives.
tRPC or oRPC?
The two options that caught my attention were tRPC and oRPC.
tRPC is a solid choice. It's mature, has a great developer experience, and works really well with TypeScript and TanStack Query.
But I wanted something more.
I didn't want to give up OpenAPI. My backend might eventually serve a mobile app, a Python service, or external integrations.
tRPC can support OpenAPI through additional tooling, but I wanted it to be a first-class feature.
That's where oRPC stood out.
What I liked about oRPC
After exploring the official comparison and documentation, a few things caught my attention.
1. RPC + OpenAPI
Define procedures once and expose them through RPC or OpenAPI-compatible HTTP endpoints. No need to maintain two separate API implementations.
2. Typed errors
You can define expected errors and get proper TypeScript support when handling them on the client. Really useful when dealing with complex business logic.
3. Better type support
Types like Date, BigInt, Map, Set, and URL work through its RPC serialization without requiring additional transformers. It also supports File and Blob.
4. Streaming
Built-in support for typed Server-Sent Events and streaming responses.
5. Good integrations
Works with TanStack Query, NestJS, Next.js, OpenTelemetry, and more.
6. Performance
The official benchmarks show some impressive results, including roughly 4x the throughput of tRPC in certain scenarios.
Of course, benchmarks don't represent every real-world application, but they're still interesting.
Why I made the switch
My requirements were simple.
I wanted the smooth developer experience of RPC, proper OpenAPI support, typed errors, and the flexibility to build APIs for different clients.
I also liked that oRPC supports contract-first development, something I appreciated about ts-rest.
oRPC gave me the combination I was looking for.
That doesn't mean it's better for everyone.
tRPC is still excellent for TypeScript-only applications, and ts-rest remains a good option for REST-first, contract-driven APIs.
I wouldn't recommend migrating a working application just because another library has more features.
But for my new project, oRPC made more sense.
Final thoughts
I didn't switch because ts-rest was bad or because oRPC was newer.
I switched because my requirements had changed, and oRPC felt like a better fit.
I'm still exploring how it holds up as my projects grow, but so far, I like the direction.
If you're evaluating TypeScript API libraries, I'd recommend checking out oRPC.
Have you tried oRPC in production? I'd love to hear your experience, especially any limitations you've encountered.
Top comments (0)