TKit/Quarkus REST client vs. devon4j REST client

[hohwille]

Quarkus:
https://quarkus.io/guides/rest-client

devon4j:
https://github.com/devonfw/devon4j/blob/develop/documentation/guide-service-client.asciidoc

We need to compare and align these approaches.

[hohwille]

IMHO the async support of devon4j is much more sophisticated. WDYT?

[hohwille]

However, the reactive support of Quarkus is great.
Maybe we can even combine both PROs in one solution...?

[matus-m]

The Quarkus provides support for several Http/REST client solutions via its extensions: JaxRS Rest client - MP Rest client, plain VertX http client, reactive JaxRS client..
The MP Rest/Resteasy based clients have benefit of being bundled - no additional client libraries are required and no impl code is required - simple definitions of JaxRS endpoints and models are sufficient to support both blocking and reactive clients(currently experimental). Switch to reactive/async is simply a matter of changing return types from plain Objects to Reactive wrappers(Response vs Uni<Response> for example. This has also support for standard JaxRS filters ( e.g. for logging, pro-active auth..)

Tkit at the moment does not provide any custom client(in terms of client impl), we do have a custom codegen that generates MP Rest client interfaces from OpenAPI(though we would like to get rid of it in favor or standard OpenAPI generator).
Additionally we then have 1 or 2 JaxRS filters for simple features like logging of outgoing/incomming requests, though these are optional.

[isandesh1986]

Hi,

I've done some comparision of Quarkus REST Client vs devon4j REST Client and listed down the below table. Please review and suggest. This is still work in progress. Thanks

[ssarmokadam]

Raised PR #27

[hohwille]

FYI: Aspects such as Resilience will IMHO be adressed outside the service client in both cases via things like Istio or any other service-mesh/side-car.

Regarding this comparison: In the end we want to open a new quarkus stack. Even though I would be biased as I designed and created the devon4j service client and love it with its plugins and excellent error handling as well as the better async support without creating artificial async methods in the service interface, I also think that if we go for quarkus we should also go for the quarkus rest client. If we discover gaps in it from this comparison, we should take this as an opportunity to improve quarkus rest client by contributing PRs. Integrating the devon4j rest client into graalvm surely could be an alternative but we want to go away from proprietary soltuions and maintaining our own stuff where suitable.