Reactive Systems in Java

Chapter 6. Quarkus: Reactive Engine

In Part II, you learned a lot about Reactive, in all its forms, meanings, and variations! I know, you’re probably a bit tired of hearing the word reactive right now, but it’s a key piece to accurately describing Quarkus. At the core of Quarkus is its reactive engine, which we cover in “A Reactive Engine”. Without its reactive engine core, Quarkus would not allow implementing reactive applications and provide a seamless integration of reactive programming.

Quarkus unifies two development models: imperative and reactive. In this chapter, we review the main differences and show how Quarkus handles the unification. Quarkus aims for them to be as alike as possible. If the APIs feel similar, understanding a complex model such as Reactive becomes seamless.

Before we can get into the reactive engine, we need to revisit the imperative and reactive models. Doing so allows us an opportunity to appreciate how they’re unified with Quarkus. For anyone already familiar with imperative and reactive models, how they work, and the benefits and disadvantages of each, feel free to skip ahead to “Unification of Reactive and Imperative”.

You might worry we’re repeating previously covered information. We might be a little, but it’s all geared toward reinforcing how the two models impact the way applications are developed—and as a result, how frameworks differ depending on the model they offer.

First up is the imperative model, which most Java developers likely started ...