vert.xquarkusmutinyvert.x-webclient

reactive inter micro service communications vert.x (emphasis on reactive)


navigating async, non blocking, and reactiveness is a handfull... given 2 non blocking, reactive, vert.x/quarkus based, micro services A and B, where the constraint is that A MUST communicate with B via http. in case I want to keep service A reactive (non blocking):

  1. should I use vertx-web-client? the docs state its an async client, but I assume that being vert.x based its non blocking as well? (i am distinguishing between async and non blocking here)
  2. in Quarkus, I see that a clone/sibling of the vertx-web-client, which is Mutiny specific, is used. Is this so that we can use Mutiny higher level APIs (like Uni/Multi). will I still get the same non blocking 'reactivity'?
  3. Java 11 has a new web client which is stated as async and reactive (I think reactive in the sense of supporting reactive streams. not sure if its the ame meaning). If I try to use this in my service A to communicate with B, will I still get the non blocking nature? or will it break it because its not vert.x based and not using netty for example? like I said I have my handsfull and my mind exploding :)

Any help would be great. thanks


Solution

  • You can use the Vert.x Web Client which has an asynchronous and non-blocking API.

    The Mutiny API for the Vert.x Web Client works with both Quarkus and Vert.x. It works the same as the bare Vert.x Web Client, except the API is based on Uni and Multi.

    I'm not very knowledgeable with the JDK11 HTTP Client. If your microservice A does nothing but sending HTTP requests to microservice B then perhaps using the JDK HTTP Client is just fine. But usually, a microservice also receives messages (HTTP, Kafka, ...etc) and interacts with a database. In this case it makes sense to leverage the integration of toolkit/framework.