Spring 5 is going to include support for the reactive programming model [1].
Here’s an example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import org.springframework.http.MediaType;
import org.springframework.http.client.reactive.ReactorClientHttpConnector;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.reactive.WebClient;
import reactor.core.publisher.Mono;
import static org.springframework.web.client.reactive.ClientWebRequestBuilders.get;
import static org.springframework.web.client.reactive.ResponseExtractors.body;
@RestController
public class ReactiveController {
@RequestMapping("/reactive-controller")
public Mono<String> sayHello() {
WebClient reactiveHttpClient = new WebClient(new ReactorClientHttpConnector());
return reactiveHttpClient
.perform(get("http://localhost:8080/traditional-controller").accept(MediaType.TEXT_PLAIN))
.extract(body(String.class));
}
}
Find a working solution at GitHub. It is based on Spring 5 milestone 1 and the current state of the experimental spring-boot-*-web-reactive libraries.
It is much like a normal Spring MVC controller. It is only the return type (Mono) that is different and the fact that the code is non-blocking itself: using the reactive HTTP WebClient.
Clearly, Pivotal believe in this model. And so do Oracle: who will include reactive types into Java 9 [2] that adheres to the Reactive Streams Specification [3]. Vert.x is another framework that is fully based on reactive programming. And there are many other languages and frameworks that supports it. So it seems like this model is here to stay.
Reasons for adopting this model
A rather pervasive promise that I have encountered is that reactive applications can exhibit superior performance. They can scale extremely well - apparently only to be limited by the networking capabilities of the underlying platform.
Thats all fine. But we’re not all Google, Facebook or Twitter. So to be honest I’m pretty satisfied with the juice that I can get out of the typical non-reactive Web application. But surely, there must be other wins too…
So what is it that makes the reactive model compelling ?
I am not going to pretend to be the expert here. But I’ve found these interesting remarks about it [4]:
- The scalability of the application is not limited by choices in the application code - nor is it limited by any configuration of the Web container thread pools etc.
- Inversion of control: The responsibility of handling the concurrency has been inverted: it is no longer the developers responsibility to tune it and get it right - it is entirely handled by the underlying platforms networking/buffering capabilities.
In my opinion that sounds really interesting. Imagine to be able to not care about tuning thread pools in the Web container - or to not care about ExecutorService threadpools tuning in the source code! Just leave it to the machinery below.
Potential issues
There’s a flipside to this as well [4]: a reactive application is likely more difficult to troubleshoot. And we can shoot ourselves in the foot if we by accident introduce blocking code (fx blocking RDBMS I/O drivers).
Add to that the fact that currently most traditional Java based integration libraries are blocking: so we will have to be creative to make it tick correctly (fx using the blocking-to-reactive pattern).
What do you think?
Are there any compelling reasons, other than those mentioned in this post, for us to switch from the imperative programming model into the reactive programming model?
References
[1] Spring 5 Milestone 1 now includes reactive functionality
[2] Doug Lea’s contribution of reactive types to JDK9
[3] The Reactive Streams Specification
[4] Notes from spring.io on reactive programming: Part 1, Part 2, Part 3