Is it possible to generate both mutiny and regular clients?

[FreifeldRoyi]

I would like to generate both options. For example, have 2 api calls in the same generated RestClient for myGetApi() and myGetApiReactive() in the same class

[ricardozanini]

Quarkus won't allow the use of Rest Classic and Rest Reactive on the same classpath.

I guess everything is reactive now (https://quarkus.io/guides/rest), so we would have to review our templates and drop classic from the upcoming 3.x version.

In that case, we can add a configuration that you can specify the proper behavior for each service. What is your use case for this?

[hbelmiro]

I have no idea about how much of our users still use the non-reactive implementation today.
But when we added the reactive support, we decided to support both so applications that depend on the classic implementation (including Kogito at the time) could use this extension.

[gastaldi]

quarkus-rest supports both reactive (returning Uni and Multi) and normal APIs. It's perfectly fine to support both models, as it's a matter of preference on how the API is exposed however using the same implementation

[FreifeldRoyi]

In that case, we can add a configuration that you can specify the proper behavior for each service. What is your use case for this?

I want to expose RestClients of each service as an SDK.
It is up to the developer who uses that SDK to decide which of reactive/regular/vthreads is preferred.

It is possible to release 2 different packages for reactive and regular, but as @gastaldi mentioned, even quarkus merged them both into one dependency.

A reasonable solution would be to expose a configuration that let's me decide which implementation I would like to add. If both are used, It should provide String myGetRequestRegular() flavor as well as Uni<String> myGetRequestReactive().

Probably with configuration for custom prefixes and suffixes 🤔

[hbelmiro]

@FreifeldRoyi two points:

It is possible to release 2 different packages for reactive and regular, but as @gastaldi mentioned, even quarkus merged them both into one dependency.

We need to use two dependencies/implementations because users may depend on one of them for particular reasons.
For example, let's say we decide to use only the reactive dependency (quarkus-rest). A user with an application that depends on the legacy implementation (quarkus-resteasy-client) wouldn't be able to use this extension because an application can't have both dependencies simultaneously.

---

It's not clear to me what you want to achieve. Can you please clarify?

I would like to generate both options. For example, have 2 api calls in the same generated RestClient for myGetApi() and myGetApiReactive() in the same class

From the above statement, I understand you want to expose two different methods: one for reactive code and one for blocking code.

I want to expose RestClients of each service as an SDK.
It is up to the developer who uses that SDK to decide which of reactive/regular/vthreads is preferred.

From the later, I understand you want to expose only one method based on a config. You can achieve this behavior with quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny=true.
See: https://docs.quarkiverse.io/quarkus-openapi-generator/dev/client.html#_resteasy_reactive

[FreifeldRoyi]

@hbelmiro sure, I'll try to clarify:
I'm using both vthreads and mutiny in several places. Not something I like doing, it just happened 😅. I try to be consistent but... well... things unfortunately happen during development 🫣. Meaning that I can use vthreads in one service, and mutiny in the other (obviously, not in the same flow).
So I would like to have both options exposed.

It is up to the developer who uses that SDK to decide which of reactive/regular/vthreads is preferred.

What I meant by that is that it is up for the who uses that generated client, which implementation they are going to use.

[ricardozanini]

wouldn't be able to use this extension because an application can't have both dependencies simultaneously.

@hbelmiro, for 3.x, I'll drop support to classic, and people who want to upgrade will have to change on their side. We can provide support for 2.x for a while and fix CVEs and whatnot, but we won't backport features anymore. I'll probably work on this on 2025/Q2.