Chapter 12. Persisting data reactively

 

This chapter covers

  • Spring Data’s reactive repositories
  • Writing reactive repositories for Cassandra and MongoDB
  • Adapting non-reactive repositories for reactive use
  • Data modeling with Cassandra

As I think about non-blocking reactive code and blocking imperative code, I start to think about rush hour. Rush hour is strangely named. Everybody seems to be in a rush to get where they’re going, but usually they’re all sitting near-motionless in traffic. If it weren’t for everyone else on the road, I’d have no trouble getting to my destination.

Even though I’m eager to get somewhere (I’m non-blocking), that doesn’t mean that someone else on the road isn’t blocking me somehow. There may be other motorists ahead who have had a fender bender and are literally blocking the road for other commuters. So even though my efforts to get home are essentially non-blocking, I’m still blocked until the accident scene is cleared up.

In the previous chapter, you saw how to create reactive, non-blocking controllers with Spring WebFlux. This helps to improve scalability in the web layer. But those controllers are only truly non-blocking if other components that they work with are also non-blocking. If we write Spring WebFlux controllers that still depend on blocking repositories, our reactive controllers will be blocked waiting for them to produce data.

12.1. Understanding Spring Data’s reactive story

12.2. Working with reactive Cassandra repositories

12.3. Writing reactive MongoDB repositories

Summary