Generated oRPC Client from any OpenAPI Spec?

[unnoq]

Your backend + oRPC Client?

[isrmicha]

Will be great, we got some generators for ts-rest and zodios as well, we could have this on oRPC
https://github.com/Carminepo2/openapi-ts-rest

https://github.com/astahmer/openapi-zod-client

[unnoq]

Thanks for your links, I will dig into to see the best way to implement it for oRPC

[izziaraffaele]

I came across oRPC today looking for ts-rest alternative for typing third-party APIs that do not provide a typescript SDK. The only reason I would choose ts-rest over oRPC today is that ts-rest is "API Design Agnostic" as stated in their homepage.

@unnoq does this use case fit it this discussion? Will oRPC be "API Design Agnostic" (at least on the client) soon?

[izziaraffaele]

To be honest I haven't tried oRPC yet, I just discovered it yesterday and I was focusing mainly on reading the doc.

While ts-rest doc clearly says in many palces that you can use the client without the server and the server without the client, your doc hints the opposite. From the following link it seems that to create a client I need to use an RPCLink and a server using RPCHandler.

https://orpc.unnoq.com/docs/client/client-side#creating-a-client

If that's not the case I suggest you to update the doc adding an example of using the client with any other REST api which does not use RPCHander (ts-rest has an example with the PokeApi and HackerNews)

Anyways... at this point I guess a just have to try oRPC to see if it fits my use-case 😄

[unnoq]

oRPC more widely features thank you think, for the wrapping any other REST, you can do that with contract (or generate it)+ OpenAPILink

[izziaraffaele]

Yes, I'm familiar with contract first development and I had previously seen your doc about it. The misleading statements IMHO are:

To use OpenAPILink, you must have a contract router and a server configured with an OpenAPIHandler.

Before using RPCLink, ensure your server is running an RPCHandler.

[unnoq]

Thanks I will fix that, I mention it because user usually mislead between RPC and OpenAPI in oRPC

[izziaraffaele]

I can imagine how complex it is to have a well structured and useful doc that works for every developer. You're doing a great job! Keep on going!!

[Quatton]

I'm sooo invested in this. lmk if we're pushing this project.

[unnoq]

How you do that, what is strategy?

[Quatton]

I think we will need to rely on codegen based on OpenAPI spec regardless.

Since oRPC client can be type-only*, we could codegen the type stubs that mimics the contract router. Primarily we can use operationId as key. This is similar to what Supabase does to createClient<Database>().

Another strategy is directly generating the contract router, but that's very ambitious.

*Edit: I just realized OpenAPILink stills need the contract object itself.

[unnoq]

What do you think about generating contracts from OpenAPI like this?

export const contract: /* GENERATED TYPES */ = /* GENERATED CONTRACT */;

I’d also like to optionally embed the corresponding input/output JSON Schemas within the contract — mainly to support native types like URL in the future.

Another strategy I’m considering is to focus exclusively on OpenAPI 3.1. If OpenAPI 4.0 gets released, we upgrade everything to 4.0. For earlier versions (like 3.0), we’d convert them to 3.1 as a preprocessing step.

Thoughts?

[Quatton]

Yeah, directly generating the contract router would be ideal. It also helps with migrating server to another language or generating a mock server. Frontend and backend in large teams being able to work independently in a type safe way is a huge value.

About the version, locking to OpenAPI 3.1 with all the incompatible types included as metadata would be fine. I'm not sure how much OpenAPI 4.0 might change.

Because oRPC's Route type is already a plain object and ContractRouter is also a nested object, we might theoretically be able to convert from-to OpenAPI. The non-trivial part is the input/output schema and tags grouping which I'm not quite sure of yet.

[unnoq]

#547