Reactive programming scales insanely well because of efficient resource usage. Keep in mind, that a reactive programming model is associated with costs: Steep learning curve, readability of code changes fundamentally, an entirely different debugging experience. My take on whether you should switch to reactive programming is:

Don’t do reactive because it’s fancy, do reactive because you have to.

Good reasons to apply reactive programming are:

  • Scalability requirements
  • Streaming of vast amounts of data
  • Active streaming of live data/pushing events to consumers

The R2DBC Tour has just started. Most significants learnings are about use-cases that are solved today with imperative/asynchronous programming and that can be solved in a more efficient way using reactive programming. Here are some impressions from the first talks in Bucharest at Voxxed Days Bucharest, Karlsruhe, Saarbrücken, and Mannheim.

In Bucharest, we had a great opportunity to discuss R2DBC with members of the MicroProfile community to see how MicroProfile could integrate with R2DBC with providing a client library on top of R2DBC.

Karlsruhe was a lot of fun and we had a good discussion when reactive programming makes sense and when it does not. Having an existing application is a good example of leaving things as is. Starting fresh with scalability requirements makes a good case for reactive programming if your team is willing and able to cope with a reactive mindshift. Still, you can benefit from reactive programming for individual, specific use-cases. Server-Sent-Events is one of these.

In Mannheim we discussed parameter bind markers in detail and how this compares to bind markers we are used to. Switching from anonymous (?) bind markers to named or indexed bind markers requires rethinking. In some cases it's important to retain portability across various databases. In other cases, portability is a non-issue.

R2DBC Tour continues next week in Berlin (at microXchg), Aachen, Paderborn, Hamburg, and Hannover. Stay tuned!