Using oRPC as BFF + typed HTTP client for 3rd-party APIs (OpenAPI + manual contracts)

[stychu]

Hi 👋

First off: great work on oRPC — I really like the contract-first approach and the focus on type safety across the whole pipeline.

I want to confirm whether oRPC fully supports a use case I’m evaluating it for.

Context

I currently have:

• Next.js app with a custom Express server
• tRPC for frontend ↔ BFF communication
• The app acts as a BFF that connects to multiple 3rd-party REST APIs

The main problem I’m trying to solve:

• Some external APIs do not provide OpenAPI specs → require manual typing

• Some do provide OpenAPI specs

• I want end-to-end type safety:

  • 3rd-party API → BFF → browser

This is where oRPC looks very promising, potentially replacing:

• manual HTTP clients
• OpenAPI codegen tools
• and tRPC itself

What I want to confirm

1. oRPC as a typed HTTP client for 3rd-party APIs (no server)

Is this a supported and intended usage?

• Define an oRPC contract manually for a 3rd-party REST API that has no OpenAPI spec

• Create an oRPC client that:

  • talks directly to the external API over HTTP
  • no oRPC server involved

• Use that client inside my BFF like a typed SDK

Essentially:

“oRPC as a contract-driven, typed HTTP client”

2. OpenAPI → oRPC → HTTP client (no manual contract writing)

For APIs that do provide OpenAPI specs:

• Ingest a static OpenAPI spec
• Generate an oRPC contract from it
• Create an oRPC client that calls the external API
• Optionally narrow the exposed surface to a subset of endpoints

No proxy server, just:

OpenAPI → oRPC contract → oRPC client → external REST API

3. Replacing tRPC for BFF ↔ frontend

Finally:

• Use oRPC for BFF ↔ frontend communication

• Reuse or adapt contracts where possible

• Have a single, consistent type-safe model from:

  • external API calls
  • through the BFF
  • to the browser

Summary question

If all of the above is supported, then oRPC would be a full, unified solution for:

• typed 3rd-party API clients (manual + OpenAPI)
• and typed BFF ↔ frontend communication

Before committing to a migration from tRPC, I want to confirm:
👉 Is this usage fully supported and aligned with oRPC’s design goals?

Thanks in advance — happy to clarify or provide a concrete example if helpful.

[dosubot[bot]]

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

Yes, oRPC supports the unified usage you described and this approach is aligned with its design goals.

1. Typed HTTP client for 3rd-party APIs (manual contracts, no server):
   You can define oRPC contracts manually for external APIs (even if they don’t provide OpenAPI specs) and use them to create type-safe HTTP clients in your BFF, without running an oRPC server. This is a documented and supported pattern—just use ContractRouterClient and createORPCClient with your contract, and you get a typed SDK for the external API in your BFF [example].

2. OpenAPI → oRPC contract → HTTP client:
   For APIs with OpenAPI specs, you can ingest the spec and generate an oRPC contract (using integrations like Hey API or planned built-in tools). You can then create a type-safe oRPC client that talks directly to the external API—no proxy server required. You can also filter/narrow the contract to expose only a subset of endpoints [docs, discussion].

3. Replacing tRPC for BFF ↔ frontend:
   oRPC is designed for contract-first, end-to-end type safety. You can reuse or adapt contracts for both 3rd-party API clients and BFF-to-frontend communication, enabling a single, consistent type-safe model from external API calls through your BFF to the browser [docs].

Caveats & limitations:

• OpenAPI integration is robust but not 100% feature-complete: some native types (like Set, Map, Date) and complex OpenAPI features may require custom extensions or have partial support [discussion].
• Middleware integration in Express/Fastify/NestJS has some architectural limitations (response handling can break middleware chains), but improvements are planned for v2 [roadmap].
• Generating a typesafe client directly from an OpenAPI spec is possible (with Hey API or similar), but seamless workflows are still evolving [discussion].

Best practices:

• For manual contracts, use ContractRouterClient and avoid leaking server logic to the client.
• For OpenAPI, generate the contract/spec at build time and import it as JSON for best performance and type safety.
• Use the filter option when generating contracts/specs to narrow the API surface as needed.

This usage pattern is actively supported and matches the direction of oRPC’s ecosystem. If you want concrete code examples or have edge-case requirements, let me know!

To reply, just mention @dosu.

---

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

   

[unnoq]

1. Yes
2. Yes
3. Yes

[stychu]

That dosu is handy. I love it especially giving some resources <3

[unnoq]

I’m confident that oRPC currently supports your use cases, though not 100%. There are a few edge cases: for example, how oRPC determines whether a request contains file uploads or JSON data if Content-Type=Applidation/JSon. Right now, it’s treated as JSON if there's no Content-Disposition header, which can be misleading in some cases. These will be improved in v2.

[stychu]

Should not be a problem in my use case atm but good to know. Love that v2 will improve on these.
Well then... Im getting right into the refactoring to oRPC <3 ! Thank you @unnoq this is really nice piece of software 💪