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.