13 Persisting data reactively

If we’ve learned one thing from science fiction, it’s that if you want to improve upon past experiences, all you need is a little time travel. It worked in Back to the Future, several episodes of various Star Trek shows, Avengers: Endgame, and Stephen King’s 11/22/63. (OK, well maybe that last one didn’t turn out better. But you get the idea.)

In this chapter, we’re going to rewind back to chapters 3 and 4, revisiting the repositories we created for relational databases, MongoDB, and Cassandra. This time, we’re going to improve on them by taking advantage of some of Spring Data’s reactive repository support, allowing us to work with those repositories in a nonblocking fashion.

Let’s start by looking at Spring Data R2DBC, a reactive alternative to Spring Data JDBC for persistence to relational databases.

13.1 Working with R2DBC

Reactive Relational Database Connectivity, or R2DBC (https://r2dbc.io/) as it is commonly known, is a relatively new option for working with relational data using reactive types. It is effectively a reactive alternative to JDBC, enabling nonblocking persistence against conventional relational databases such as MySQL, PostgreSQL, H2, and Oracle. Because it’s built on Reactive Streams, it is quite different from JDBC and is a separate specification, unrelated to Java SE.

13.1.1 Defining domain entities for R2DBC

13.1.2 Defining reactive repositories

13.1.3 Testing R2DBC repositories

13.1.4 Defining an OrderRepository aggregate root service

13.2 Persisting document data reactively with MongoDB

13.2.1 Defining domain document types

13.2.2 Defining reactive MongoDB repositories

13.2.3 Testing reactive MongoDB repositories

13.3 Reactively persisting data in Cassandra

13.3.1 Defining domain classes for Cassandra persistence

13.3.2 Creating reactive Cassandra repositories