CODEWITHSUNDEEP
project-reactorspring-data-r2dbcr2dbc
lives
lives

Reputation: 1195

Reactive R2DBC for simple RESTful calls

Since R2DBC is reactive and non blocking I would like to understand the benefit of using R2DBC in a simple RESTful CRUD service

Assume a spring boot application is exposing a RESTful service using a repository below

public interface CustomerRepository extends ReactiveCrudRepository<Customer, Long> {

    @Query("SELECT * FROM customer WHERE last_name = :lastname")
    Flux<Customer> findByLastName(String lastName);

}

This repository is called from a service and the results needs to be transformed in the service before returning to controller.

Flux<Customer> customers = repository.findAll();

In order to access the complete list of customers , I need to invoke blockLast() on the Flux which makes it blocking and defeats the purpose of using reactive components

Does that mean that there is no benefit of using R2DBC in this simple example ? Am I missing something ?

Can flux be used only for asynchronous subscription where the processing of Flux collections happens in a different thread ?

Upvotes: 5

Views: 976

Answers (2)

Prashant Pandey
Prashant Pandey

Reputation: 4682

  1. Since the method retuns a Flux, it returns a promise that can complete sometime in future.
  2. The thread calling this method should not block - that's the whole point of reactive. If you use .blockLast(), you will make the calling thread block. As Michael said in this answer, this should only be done when you are integrating reactive and non-reactive code together.
  3. Here is a diagram that explains how async. computations are work (reactive, CompletableFuture, etc.). Hopefully this clears your doubts;

enter image description here

As you can see in the diagram, if you do .blockLast(), you lose out on true non-blocking. Ideally, the calling thread should get free immediately so that it can do other work.

  1. A properly written reactive application will be a single chain with the subscription happening at the upper-most layer. The entire application should be an async pipeline. You should use applications like BlockHound to check if your threads are blocking anywhere.

"Can flux be used only for asynchronous subscription where the processing of Flux collections happens in a different thread ?" - Flux is nothing but a promise that says it can finish some time in future. As the diagram shows, callbacks will execute on the thread that the async. computation finished on. You can switch this thread using .publishOn().

Upvotes: 2

Michael Berry
Michael Berry

Reputation: 72399

In order to access the complete list of customers , I need to invoke blockLast() on the Flux which makes it blocking and defeats the purpose of using reactive components

You only need to call blockLast() if you want to actually obtain a reference to a List<Customer> - but as you say, if you do that, you lose all the reactive advantages. (The only time you should really consider blocking IMHO is if you're migrating to a reactive system, and putting reactive libraries in place, but not yet ready to make the whole system reactive.)

If you just want to access the complete list of customers at once, you might sensibly call collectList() to get a Mono<List<Customer>. That way you stay in a reactive context, but in any reactive operator you have the entire list available.

The only thing to watch out for here is the memory footprint - if you just process a Flux<Customer> as-is, then you never need to store a group of them in memory so it really doesn't matter how many there are (it can even be infinite.) If you collect it to a list first, then all of those customers then have to be stored in memory simultaneously.

Whether this is a problem depends on your use-case. If you're talking about 10 or so customers, no problem at all. If you're talking about billions, then chances are that's not going to be a sensible solution.

Upvotes: 4

Related Questions