Question about Chapter 7 createReview in Review service

[Terry Bui]

From my understanding, reading through the book and code for section 7. When the Product Composite service creates new Product, Recommendations and Reviews, it would put the request on respectively topic where the core microservices will take from the queue and action it according to it message type.

For Product and Recommendation, since it using MongoDB which has support for non-blocking model, it using reactive programming. But for Review case, reading the code inside ReviewServiceImpl createReview, it creates review in a blocking sync manner? Is my understanding correct? I was wondering if using a threadpool is a improvement if the above case is correct?

Hands-On-Microservices-with-Spring-Boot-and-Spring-Cloud/Chapter07/microservices/review-service/src/main/java/se/magnus/microservices/core/review/services/ReviewServiceImpl.java

Lines 45 to 59 in 0035a59

 public Review createReview(Review body) { 
  
     if (body.getProductId() < 1) throw new InvalidInputException("Invalid productId: " + body.getProductId()); 
  
     try { 
         ReviewEntity entity = mapper.apiToEntity(body); 
         ReviewEntity newEntity = repository.save(entity); 
  
         LOG.debug("createReview: created a review entity: {}/{}", body.getProductId(), body.getReviewId()); 
         return mapper.entityToApi(newEntity); 
  
     } catch (DataIntegrityViolationException dive) { 
         throw new InvalidInputException("Duplicate key, Product Id: " + body.getProductId() + ", Review Id:" + body.getReviewId()); 
     } 
 } 

[Magnus Larsson]

Hello, and thanks for your question!

The thread pool is only used for the otherwise reactive implementation of the GET HTTP request:

public Flux<Review> getReviews(int productId) { ... }

Does this answer your question?

[Terry Bui]

Thank you for the response. Is there a reason why we not using the thread pool inside createReview(Review body)?

[Magnus Larsson]

No, not really. As they are used in the book, the use in the MessageProcessor of the create and delete method needs to be blocking to get the error handling to work with Spring Cloud Stream. But to make them more reusable, e.g. from a reactive consumer, they should have been implemented in the same way as the get method. So a better implementation would be to make the create and delete method reactive and then call the .block() metod in the MessageProcessor, i.e. in the component that needs the blocking implementation.