13.2.2 Creating reactive Cassandra repositories

By now you may already be expecting the reactive Cassandra repositories to look a lot like the equivalent nonreactive repositories. If so, then great! You’re catching on that Spring Data, wherever possible, attempts to maintain a similar programming model regardless of whether or not repositories are reactive.

You may have already guessed that the only key difference that makes the repositories reactive is that the interfaces extend ReactiveCrudRepository, as shown here in the IngredientRepository interface:

package tacos.data;

import org.springframework.data.repository.reactive.ReactiveCrudRepository;

import tacos.Ingredient;

public interface IngredientRepository
      extends ReactiveCrudRepository<Ingredient, String> {
}

Naturally, the same holds true for OrderRepository, as shown next:

package tacos.data;

import java.util.UUID;

import org.springframework.data.domain.Pageable;
import org.springframework.data.repository.reactive.ReactiveCrudRepository;

import reactor.core.publisher.Flux;
import tacos.TacoOrder;
import tacos.User;

public interface OrderRepository
      extends ReactiveCrudRepository<TacoOrder, UUID> {

  Flux<TacoOrder> findByUserOrderByPlacedAtDesc(
      User user, Pageable pageable);
}

In fact, not only are these repositories reminiscent of their nonreactive counterparts, they also do not differ greatly from the MongoDB repositories we wrote earlier in this chapter. Aside from Cassandra using UUID as an ID type instead of String for TacoOrder, they are virtually identical. This once again demonstrates the consistency employed (where possible) across Spring Data projects.

Let’s wrap up our look at writing reactive Cassandra repositories by writing a couple of tests to verify that they work.