What is preferred/idiomatic way to use oRPC with platform or framework adapters?

[valerii15298]

There are multiple adapters for different platforms - node/bun/deno
And for different frameworks - hono/next/express/fastify etc...

What is the most idiotic way to use oRPC? When using some framework there will be additional level of abstraction and overhead.
When using platform specific adapter it should be less overhead, but lees functionality.

For now I am using hono on top of node.js and attaching orpc to hono. I am considering to drop hono and use orpc directly with node.js adapter. But there are auth part with hono which uses cookie helper from hono(hono has cookies validation with zod schemas which oRPC for now does not have, - I can parse cookies from headers manually, use some cookie parsing library etc...)

What could be other advantages and disadvantages when switching to directly using platform adapter with orpc(so basically using oRPC as main backend framework)?

Would it make sense to add cookies validation to oRPC? I am not sure.
There is already headers validation with inputStructure: 'detailed', mode: https://orpc.unnoq.com/docs/openapi/input-output-structure#detailed-mode
So it is possible to add zod schema for Cookie header with some parsing etc, though it would be more verbose and custom way but workable I guess(did not try it yet though)

[dosubot[bot]]

Hi @valerii15298! I'm Dosu and I’m helping the orpc team.

There’s no single “preferred” way—oRPC is designed to be flexible, so both platform and framework adapters are valid depending on your needs. Using a framework adapter like Hono gives you middleware, cookie parsing, and helpers (like Zod-based cookie validation), but adds a layer of abstraction and some overhead. Using a platform adapter (like node.js) is more minimal and performant, but you’ll need to handle things like cookie parsing and authentication yourself, usually with third-party libraries.

If you drop Hono and use oRPC directly with the node adapter, you lose Hono’s cookie helpers and will need to implement or integrate your own cookie/auth logic. oRPC doesn’t provide built-in cookie parsing or Zod validation for cookies—this is left to userland or external libraries. The trade-off is convenience and features (framework) vs. control and minimalism (platform). There’s no official recommendation—maintainers suggest picking the adapter that best matches your use case and environment. Both approaches are idiomatic and supported in the codebase and examples; it’s just a matter of what fits your project best discussion issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[unnoq]

• Hono is slow on Node, so if you use oRPC without Hono you can improve performance, memory usage, ...
• Cookie parsing is missing feature that oRPC not provide, you need to manually handle it
• You should not add cookie validation, auth behavior should be implicit handle in middleware (for example)

My recommendation is always use oRPC standalone until you need things that oRPC not provide.