Reactive programming processes data and events asynchronously, often by dividing large tasks into subtasks that can progress simultaneously. Clients can receive processed data sooner instead of waiting for an entire task to finish. section 17.0
Reactive applications differ from imperative applications in several practical ways:
- Process data in fragments as it arrives instead of waiting for the complete dataset. section 17.1
- Use Reactive Streams as a standard for asynchronous stream processing. section 17.1
- Use Project Reactor to compose streams through a functional API and provide the foundation for Spring’s reactive programming model. section 17.1
- Avoid storing authentication details only at thread level because one request’s tasks can run on multiple threads. section 17.1
A minimal reactive endpoint
A Spring WebFlux controller can return a Mono<String> from a /hello endpoint, producing the response through a reactive type rather than returning the string directly. section 17.1
Figure 17.1 Non-reactive vs. reactive. In a non-reactive approach, the milk factory gets all the milk to be packaged in the morning and delivers all the boxes in the evening. In a reactive approach, as the milk is brought to the factory, it’s packaged and then delivered. For this scenario, a reactive approach is better as it allows milk to be collected throughout the day and delivered sooner to the clients.
Compare imperative batch processing with reactive processing through a milk-factory analogy: reactive delivery begins as inputs arrive, so clients receive results sooner. section 17.1
