Source: https://quarkus.io/guides/getting-started-reactive
Quarkus is a Reactive framework. Since the beginning, Reactive has been an essential tenet of the Quarkus architecture. It includes many reactive features and offers a broad ecosystem.
This guide is not an in-depth article about what Reactive is and how Quarkus enables reactive architectures. If you want to read more about these topics, refer to the Reactive Architecture guide, which provides an overview of the Quarkus reactive ecosystem.
Imperative vs. Reactive: a question of threads
To better understand the contrast, we need to explain the difference between the reactive and imperative execution models. It’s essential to comprehend that Reactive is not just a different execution model, but that distinction is necessary to understand this guide.
In the traditional and imperative approach, frameworks assign a thread to handle the request. So, the whole processing of the request runs on this worker thread. This model does not scale very well. Indeed, to handle multiple concurrent requests, you need multiple threads; and so your application concurrency is constrained by the number of threads. In addition, these threads are blocked as soon as your code interacts with remote services. So, it leads to inefficient usage of the resources, as you may need more threads, and each thread, as they are mapped to OS threads, has a cost in terms of memory and CPU.
On the other side, the reactive model relies on non-blocking I/Os and a different execution model. Non-blocking I/O provides an efficient way to deal with concurrent I/O. A minimal amount of threads called I/O threads, can handle many concurrent I/O operations.
With such a model, request processing is not delegated to a worker thread but uses these I/O threads directly. It saves memory and CPU as there is no need to create worker threads to handle the requests. It also improves the concurrency as it removes the constraint on the number of threads. Finally, it also improves response time as it reduces the number of thread switches.
From sequential to continuation style
So, with the reactive execution model, the requests are processed using I/O threads. But that’s not all. An I/O thread can handle multiple concurrent requests.
How? – When processing a request requires interacting with a remote service, like an HTTP API or a database, it does not block the execution while waiting for the response. Instead, it schedules the I/O operation and attaches a continuation, i.e., the request processing remaining code. This continuation can be passed as a callback (a function invoked with the I/O outcome), or use more advanced constructs such as reactive programming or co-routines.
Regardless of how the continuation is expressed, the essential aspect is the release of the I/O thread and the fact that this thread can then be used to process another request. When the scheduled I/O completes, the I/O thread executes the continuation, and the processing of the pending request continues.
So, unlike the imperative model, where I/O blocks the execution, reactive switches to a continuation-based design, where the I/O threads are released, and continuation invoked when the I/Os complete. As a result, the I/O thread can handle multiple concurrent requests, improving the overall concurrency of the application.
But, there is a catch. We need a way to write continuation-passing code. There are many ways of doing this. In Quarkus, we propose:
- Mutiny – an intuitive and event-driven reactive programming library
- Kotlin co-routines – a way to write asynchronous code in a sequential manner
In this guide, we will use Mutiny. To know more about Mutiny, check the Mutiny documentation.
Bootstrapping the Reactive Fruits applicatio
The last extension is the reactive database driver for PostgreSQL. Hibernate Reactive uses that driver to interact with the database without blocking the caller thread.
Once selected, click on “Generate your application”, download the zip file, unzip it and open the code in your favorite IDE.
Related Guides
https://quarkus.io/guides/quarkus-reactive-architecture
https://quarkus.io/guides/mutiny-primer