As promised, here is the second part of the introduction to Reactive Programming. Last time, we discussed with Clement Escoffier who presented Reactive Programming with Vert.x to us.

Today, we meet with Simon Basle, who’s going to tell us a bit more about Reactor and how exciting times are for the project a few weeks before the release of a major version of the Spring Framework.

For the occasion, Simon and the team have created a playground to get familiar with the Reactor API:

Reactive Programming with Reactor 3 🤓🖥✅💯

Simon works as a software engineer at Pivotal, on the Reactor project. He’s been enthusiastic about reactive programming since the early days of RxJava, but also takes an interest in various topics like concurrent programming, software design aspects, what lies beyond code (best practices and user experience) and even rich clients.

Reactor logo


[Thibaud] — How would you define Reactive Programming?

[Simon] — Reactive Programming is a different approach to asynchronous programming. By thinking about your data in terms of flow, you can be declarative about asynchronous processing of that data. That works not only for single values (like with Futures) but multiple or infinite sequences as well!

Reactive libraries like Reactor or RxJava offer a rich API over these concepts, with out-of-the-box operators that allow you to describe a lot of complex transformations easily in a chain. Once you get accustomed to the vocabulary, the code is also much more readable and maintainable than some callback hell.

[Thibaud] — Can you tell me more about Reactor? How are you involved in the project?

[Simon] — Reactor is a Reactive Programming library built on the JVM, on top of the Reactive Streams (RS) specification. RS defines base interfaces and codifies their interactions, allowing interoperability between libraries like RxJava 2 and Reactor 3. But it doesn’t define any operator, and that’s where Reactor comes in.

The core of the team consists of the lead maintainer and me. Four other people gravitate around the project and contribute. We also collaborate a lot with the maintainer of RxJava, David Karnok (there’s even an experimental playground that is common to RxJava and Reactor around Reactive Streams operators, which served as a foundation for many operators in both libraries).

[Thibaud] — I’ve heard that there is an important incoming milestone for the project.

[Simon] — Indeed, the next major version of the Spring Framework, due in September, has put a huge focus on reactive programming. It has moved to a Java 8 baseline and now offers a second stack for web applications, in addition to Spring MVC: Spring WebFlux.

Based on Reactor, WebFlux is fully asynchronous and non-blocking, completely ditching the blocking Servlet model and API. By default, the underlying networking is done by Netty. Now, you can not only program asynchronous web controllers using reactive types like Flux or Mono from Reactor, but also types like Flowable from RxJava 2. All the plumbing is done with Reactor, though. That is certainly a huge milestone for us.

And if you have a datastore that has asynchronous drivers like Redis, Cassandra, Couchbase or MongoDB, you can be reactive from end to end, since Spring Data Kay has also joined the reactive world.

[Thibaud] — What happens next? What do you see in the future for Reactor?

[Simon] — I think that serviceability and tooling are the next big steps. Being able to introspect a reactive chain or have some IDE integrations or tooling capable of warning you in case you block inside a reactive chain (a big no-no)…

There’s also the problem of contextual information. This was previously handled via ThreadLocal. However, this is not a good approach for a library that can –and will– use the same thread for different processing chains, and where you can jump from thread to thread at will. So we are going to offer some form of Context attached to a Flux rather than a Thread.

[Thibaud] — We’re very glad that you chose to write a tutorial for Reactor 3 on Tech.io. What’s your feeling about the platform?

[Simon] — I think this is a great idea. The fact that you can jump into a playground from any computer and start getting your hands dirty with a new tech without bothering to set up an environment and IDE is such a boon. The tutorial’s code is a workshop that has been presented at conferences in the past. We have always had some setup problems — attendees with an exotic IDE setup or who simply forgot to download the project and dependencies on a slow wifi…

[Thibaud] — Is there a way we could improve the platform to see more reactive programming on Tech.io?

[Simon] — I’d love to see some advanced examples of visualization. Maybe I will find some inspiration to create more visual playgrounds. Being able to see the data flowing into your reactive chain (or something like that) would be great.

I see the community of playground authors grow; I think that you guys collect good feedback, so things like the playground build process, course source format, etc., continue to evolve. That’s great!

[Thibaud] — Thank you very much, Simon, for having answered my questions. I hope that Reactor will meet a well deserved success with the release of Spring.


If you’ve got any questions for Simon, don’t hesitate to use the comments below!