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)

Chapter 2: The Publisher and Subscriber APIs in a Reactor

  1. How can we validate Reactive Streams publisher and subscriber implementations?

In order to validate a publisher, the Reactive Streams API has published a test compatibility kit called reactive-streams-tck. Reactive publisher can be verified using the PublisherVerifier interface. Similarly, a subscriber can be verified by using the SubscriberBlackboxVerification<T> abstract class.

  1. How is the Reactive Streams publisher-subscriber model different from the JMS API?

In JMS, the producer is responsible for generating unbounded events on the queue or topics, while the consumer actively consumes the events. The producer and consumer are working in isolation, at their own rates. The task of managing the subscription is taken care of by the JMS broker. There is no concept of backpressure in JMS. Also, it lacks event modeling...