Quarkus Mutiny and Imperitave vs Reactive

Question

TL;DR: which is more pattern? Using Mutiny + Imperative resteasy, or just use Reactive resteasy?

My understanding is Mutiny allows for me to pass Quarkus a longer running action, and have it handle the specifics of how that code gets run in the context. Does using Reactive provide equal or more benefit than Mutiny+imperative? If from a functional point of view from a thread handling perspective it's equal or better, then Reactive would be great as it requires less code to maintain (Creating Unis, etc). However, if passing a Uni back is significantly better, then it might make sense to use that.

https://quarkus.io/guides/getting-started-reactive#imperative-vs-reactive-a-question-of-threads

Mutiny + imperative:

@GET
    @Path("/getState")
    @Produces(MediaType.APPLICATION_JSON)
    public Uni<State> getState() throws InterruptedException {
        return this.serialService.getStateUni();
    }

Reactive:

@GET
    @Path("/getState")
    @Produces(MediaType.APPLICATION_JSON)
    public State getState() throws InterruptedException {
        return this.serialService.getState();
    }

Answer 1

As always, it depends. First, I recommend you to read https://quarkus.io/blog/resteasy-reactive-smart-dispatch/, which explains the difference between the two approaches.

It's not about longer action (async != longer); it's about dispatching strategies.

When using RESTEasy Reactive, it uses the I/O thread (event loop) to process the request and switches to a worker thread only if the signature of the endpoint requires it. Using the I/O thread allows better concurrency (as you do not use worker threads), reduces memory usage (because you do not need to create the worker thread), and also tends to make the response time lower (as you save a few context switches).

Quarkus detects if your method can be called on the I/O thread or not. The heuristics are based on the signature of the methods (including annotations). To reuse the example from the question:

• a method returning a State is considered blocking and so will be called on a worker thread
• a method returning a Uni<State> is considered as non-blocking and so will be called on the I/O thread
• a method returning a State but explicitly annotated with @NonBlocking is considered as non-blocking and so will be called on the I/O thread

So, the question is, which dispatching strategy should you use? It really depends on your application and context. If you do not expect many concurrent requests (it's hard to give a general threshold, but it's often between 200 and 500 req/sec), it is perfectly fine to use a blocking/imperative approach. If your application acts as an API Gateway with potential peaks of requests, non-blocking will provide better results.

Remember that even if you choose the imperative/blocking approach, RESTEasy Reactive provides many benefits. As most of the heavy-lifting request/response processing is done on the I/O thread, you get faster and use less memory for... free.