The Reactive Manifesto
You might have heard about the Reactive Manifesto, a document that describes a set of principles for designing reactive systems.
These systems have the following characteristics:
- Responsiveness. The system must provide fast and consistent response times.
- Resilience. The system must stay responsive even after failure.
- Elasticity. The system must stay responsive even after increasing workload.
- Message-driven. The system uses asynchronous messages for communication between its components.
But, as you can see, it’s an architectural style. It’s different from reactive programming.
You can build a reactive system without using reactive programming as long as the system is designed with the principles described above.
Yes, messages and events are both, non-blocking and asynchronous, but they refer to different things and operate at different levels of abstraction.
A message is some data (usually an object) sent to a particular address. In this case, a message broker like Apache Kafka or RabbitMQ is in charge of the communication.
On the other hand, events in reactive programming are actions or data from a source (a publisher) that the subscribers react to asynchronously using callbacks, futures, or libraries like Reactor that also offer a declarative/functional API.
In summary, reactive programming means programming in a non-blocking, asynchronous way.
With this out of the way, let’s introduce Project Reactor and set up a demo project.