Reactive Systems in Java

Conclusion

We have come to the end of this book. We have covered the principles behind reactive architectures and the technical practices to implement them with Quarkus.

A Brief Summary

In Part II, we explored reactive architectures. Reactive systems (Chapter 4) propose a different way to build distributed systems (Chapter 3). The use of message passing between the various components forming the system enables elasticity and resilience, two characteristics essential for modern applications deployed in the cloud or running in containers. But that’s not all. Reactive applications must also handle the workload in a timely fashion and use resources efficiently. This last point pushes reactive applications to use nonblocking I/O and avoids creating too many OS threads (“The Role of Nonblocking Input/Output”). The resulting execution model provides better response time and improves memory consumption. However, it does not come for free. To write such an application, you must change the way you write code. You must never block the I/O threads and so must write your code using a continuation-passing style. In this book, we have looked at reactive programming and Mutiny (Chapter 5, Chapter 7).

We also covered Quarkus, a stack to write applications in Java tailored for the cloud and containers (Chapter 2). Quarkus runs on top of a reactive engine dealing with the network and nonblocking I/O. In addition, Quarkus offers a large set of reactive APIs. The combination of the engine and the ...