Now, let's dive into the details of how reactive repositories work. A reactive repository in Spring Data works by adapting underlying database driver capabilities. Underneath there could be a Reactive Streams-compliant driver or an asynchronous driver that could be wrapped into a reactive API. Here we are going to look how the reactive MongoDB repository uses the Reactive Streams-compliant MongoDB driver, as well as how the reactive Cassandra repository is built on the asynchronous driver.
First of all, the ReactiveMongoRepository interface extends more generic interfaces—ReactiveSortingRepository and ReactiveQueryByExampleExecutor. The ReactiveQueryByExampleExecutor interface allows the execution of queries with the QBE language. The ReactiveSortingRepository interface extends the more generic ReactiveCrudRepository interface and adds the findAll method, which allows requesting the sorting order of the query result.
As a lot of reactive connectors use the ReactiveCrudRepository interface, let's look at it closely. ReactiveCrudRepository declares methods for saving, finding, and deleting entities. The Mono<T> save(T entity) method saves the entity and then returns the saved entity for further operations. Note that the save operation might change the entity object entirely. The Mono<T> findById(ID id) operation consumes the entity's id and returns results wrapped into Mono. The findAllById method has two overrides, one of each consumes IDs in the form of the Iterable<ID> collection, and the other in the form of Publisher<ID>. The only notable difference between ReactiveCrudRepository and CrudRepository besides the reactive approach is in the fact that ReactiveCrudRepository does not have pagination support and does not allow transactional operations. Transactional support for reactive persistence with Spring Data is covered later in this chapter. However, now it is the developer's responsibility to implement a pagination strategy.