13.2.2 Defining reactive MongoDB repositories

Now we’ll need to define two repositories, one for the TacoOrder aggregate root and another for Ingredient. We won’t need a repository for Taco because it is a child of the TacoOrder root.

The IngredientRepository interface, shown here, should be familiar to you by now:

package tacos.data;

import org.springframework.data.repository.reactive.ReactiveCrudRepository;
import org.springframework.web.bind.annotation.CrossOrigin;

import tacos.Ingredient;

@CrossOrigin(origins="*")
public interface IngredientRepository
      extends ReactiveCrudRepository<Ingredient, String> {
}

This IngredientRepository interface is only slightly different from the one we defined in chapter 4 in that it extends ReactiveCrudRepository instead of CrudRepository. And it differs from the one we created for Spring Data R2DBC persistence only in that it doesn’t include the findBySlug() method.

Likewise, OrderRepository is all but identical to the same MongoDB repository we created in chapter 4, shown next:

package tacos.data;

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, String> {

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

}

Ultimately, the only difference between reactive and nonreactive MongoDB repositories is whether they extend ReactiveCrudRepository or CrudRepository. In choosing to extend ReactiveCrudRepository, however, clients of these repositories must be prepared to deal with reactive types like Flux and Mono. That becomes apparent as we write tests for the reactive repositories, which is what we’ll do next.