Merge multiple open-api specs into one

[LeunensMichiel]

Hi,

We have 7 open-api specs but they all use the same api. This means that we have 7 generated folders with each their hey-api client, types, sdk etc. I'd like to import the client from one possible directory, instead of having the option to import multiple clients (for which we also have to set the auth interceptors for each and every one)

Is it possible to somehow merge the contents of this folder into one? And if not, is it possible to merge the open-api spec somehow and then use that merged result as input of the hey-api config?

Cheers!

[mrlubos]

Hi @LeunensMichiel, this isn't possible today. Are you saying you have 7 specs describing the same API? If yes, why are they separated?

As for your potential workaround, you could look at other tooling for merging specs and then pass the resulting spec to the codegen. I'd like to understand your use case though!

[LeunensMichiel]

Thank you for the quick response!

I don’t have full visibility into the backend architecture, but the core issue is that we currently have seven microservices, each generating its own types. In some cases, this results in type duplication across services (e.g., api1 and api2). In the end those 7 "orchestrators" (as we call them) are accessible through 1 endpoint

This setup exists due to historical reasons, but in the future, we plan to transition to a monorepo, which would allow us to generate types globally. Unfortunately, this is not yet possible.

Our API documentation endpoint follows this structure:
BASE_URL/v1/{SERVICE}/v3/api-docs, where {SERVICE} represents one of the seven APIs. In our script, I currently have to run hey-api seven times, which leads to the following result:

As a result, we end up with multiple clients. I’m exploring ways to simplify this process and have considered the following approaches:

• Importing all generated clients into a single mergedClient file with proper type support and using that unified client throughout the application.
• Downloading the JSON files, merging them with an OpenAPI merger package, and using the merged file as input.

I’d appreciate any insights or recommendations on this!

[mrlubos]

@LeunensMichiel My gut reaction is this goes into schema design problem space which is not something codegen should be solving. It would make sense as a separate package and then we could talk about its API, but that's a use case far too removed from what it does today.

I'm assuming you guarantee merging 7 specs would produce no conflicts, i.e. every endpoint and model is either unique or if duplicate, they're 100% equal?

If yes, my recommendation remains to stitch the specs yourself. If they're all using the same OpenAPI version, this should be dead simple to do even manually. The most I could do here is expose the fetch utilities but maybe even that isn't needed

[LeunensMichiel]

Alright, I will do that then. Thank you for your insights!