A reactive application processes data and events asynchronously in fragments rather than waiting for an entire task or request payload. This approach can deliver processed results sooner and address limitations of imperative programming, but it is not the best fit for every situation. section 17.0 section 17.1
A reactive design typically involves these behaviors:
- Receive and process data as it arrives instead of waiting for all data to become available. section 17.1
- Divide large tasks into subtasks that can be approached simultaneously. section 17.0
- Represent streams through publishers that produce values and subscribers that consume them under Reactive Streams contracts. section 17.1
- Avoid storing authentication details at thread level because one request's tasks may run on multiple threads. section 17.1
Spring WebFlux endpoint
A Spring reactive controller can return Mono<String> from a /hello endpoint, producing the response through a reactive type rather than an ordinary immediate value. A reactive OAuth 2 resource server can secure the same style of endpoint with SecurityWebFilterChain, oauth2ResourceServer(), jwt(), and a configured JWK set URI. section 17.1 section 17.4
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 batch-style imperative processing with reactive processing through a milk-factory analogy: reactive delivery begins as input arrives instead of waiting for the full batch. section 17.1
