Book Image

Hands-On Reactive Programming with Reactor

By : Rahul Sharma
Book Image

Hands-On Reactive Programming with Reactor

By: Rahul Sharma

Overview of this book

Reactor is an implementation of the Java 9 Reactive Streams specification, an API for asynchronous data processing. This specification is based on a reactive programming paradigm, enabling developers to build enterprise-grade, robust applications with reduced complexity and in less time. Hands-On Reactive Programming with Reactor shows you how Reactor works, as well as how to use it to develop reactive applications in Java. The book begins with the fundamentals of Reactor and the role it plays in building effective applications. You will learn how to build fully non-blocking applications and will later be guided by the Publisher and Subscriber APIs. You will gain an understanding how to use two reactive composable APIs, Flux and Mono, which are used extensively to implement Reactive Extensions. All of these components are combined using various operations to build a complete solution. In addition to this, you will get to grips with the Flow API and understand backpressure in order to control overruns. You will also study the use of Spring WebFlux, an extension of the Reactor framework for building microservices. By the end of the book, you will have gained enough confidence to build reactive and scalable microservices.
Table of Contents (13 chapters)

Backpressure

Backpressure is an integral part of Reactor. We have discussed it multiple times in previous chapters, but we will have a detailed look at the topic here. Let's recap the out-of-the-box support for backpressure that is available with Reactor. Each of the subscribers requests the number of events that it can process using the subscription object. The publisher must respect this limit and publish events that are less than or equal to the requested limit. This is depicted in the following diagram:

Invoking a request with Long.MAX_VALUE means requesting an unbounded number of events. The publisher can push as many events as it can. It is no longer bound by the subscriber limit.

As each subscriber is processing the received events, it can request additional events using the subscription handle. If the publisher is raising events rapidly, it must come up with a strategy...