A couple of years ago, Reactive Programming was all the rage, but it had one big issue: reactive stopped as soon as you accessed a SQL database. You had a nice reactive chain up to the database, defeating the whole purpose. Given the prevalence of SQL databases in existing and new apps, one couldn’t enjoy the full benefits of Reactive Programming but still pay the full price of complexity. Since then, the landscape has changed tremendously.

One of the talks in my current portfolio is Migrating from Imperative to Reactive. The talk is based on a demo migrating from Spring WebMVC to Spring WebFlux in a step-by-step approach. One of the steps involves installing BlockHound: it allows to check whether a blocking call occurs in a thread it shouldn’t happen and throws an exception at runtime when it happens. I’ve presented this talk several times in the previous week, both in its Java version and its Kotlin one.

Last September, I wrote how to migrate from an Imperative Programming codebase to a Reactive Programming one in a step-by-step process. Because of its popularity, I illustrated the post with a Spring Boot demo. The final result uses Mono and Flux from Project Reactor. I also made sure that no step in the processing pipeline is blocking thanks to Blockhound. I wrote the code in Java so that it could be accessible to the largest audience. But I’m still a Kotlin fan at heart.