Coming from TRPC, ORPC is a breath of fresh air. I tested out a migration from TRPC to ORPC and I found two things particularly beneficial.
The first is contract-first development which separates the contract from the implementation. This allows you to avoid codebase dependencies between your server and client. TRPC works fine when you only use your client from your server package, but if you need to export it elsewhere, e.g. a public SDK, you can easily end up with circular dependency issues and a bunch of pain.
The second is OpenAPI support. TRPC doesn't support OpenAPI generation and trpc-openapi is unmaintained. ORPC has first class OpenAPI support, which means you can use ORPC internally but expose a public OpenAPI API to customers and generate OpenAPI based clients if you want to.
I'm hoping this project gets traction since it is amazingly well done. I have zero affiliation or interest in ORPC to be clear, I just loved it from my quick tests.
Coming from TRPC, ORPC is a breath of fresh air. I tested out a migration from TRPC to ORPC and I found two things particularly beneficial.
The first is contract-first development which separates the contract from the implementation. This allows you to avoid codebase dependencies between your server and client. TRPC works fine when you only use your client from your server package, but if you need to export it elsewhere, e.g. a public SDK, you can easily end up with circular dependency issues and a bunch of pain.
The second is OpenAPI support. TRPC doesn't support OpenAPI generation and trpc-openapi is unmaintained. ORPC has first class OpenAPI support, which means you can use ORPC internally but expose a public OpenAPI API to customers and generate OpenAPI based clients if you want to.
I'm hoping this project gets traction since it is amazingly well done. I have zero affiliation or interest in ORPC to be clear, I just loved it from my quick tests.