Last year I announced the R2DBC Java User Group and recently I started the tour visiting various user groups and conferences. Reactive Relational Database Connectivity lifts a roadblock when integrating with SQL databases. It’s an Open Source standardized API across multiple database drivers and an ongoing specification effort hosted on GitHub.
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.
Second round of talks at Voxxed Days Bucharest 2019! #itisfun #vdbuh2019 @ppalaga @martin_fmi @SvenRuppert @mp911de pic.twitter.com/yEsrok94fz— Voxxed Bucharest (@VoxxedBucharest) 21. März 2019
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.
Total gespannt auf den Vortrag über Reactive Ralational Database Connectivity von @mp911de vom @SpringData Team bei @synyx_ka im Rahmen der @jugka, los geht's! pic.twitter.com/z5PMbpLAWK— Jochen Binder (@jojobinder) 13. März 2019
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.
All set for @R2DBC at @jugsaar pic.twitter.com/J52GnPV4JX— Mark Paluch 👨💻&🎹 (@mp911de) 26. März 2019
Reactive Relational Database Connectivity @r2dbc presented by @mp911de pic.twitter.com/1UB32GtGbk— Mannheim Java User Group (@majug) 27. März 2019
After one day spark training in Frankfurt. The last program today @majug learn #r2dbc from @mp911de thanks!!! https://t.co/6ZUWFyngmY pic.twitter.com/Ut2HuDMBrj— Bin (@woo2333) 27. März 2019
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!