WebFlux using WebClient for blocking REST call

Question

I have a situtation where I can either use blocking I/O library that access REST endpoint on outside service or I can directly call that REST with HttpClient like WebClient in this case. Now I wonder if there are any performance diffrences between wrapping call on that library and publishing it on Elastic thread or using WebClient to access endpoint.

How exactly are calls handled with both of this options. So let's say webflux uses single thread to process request. Request is then being handled with WebClient. Does that mean the thread or event will be blocked until request recieves all data and passes it back to the client? I'm also intrested where does EventLoop come in, does it come with WebClient or already at controller/service layer.

This is the alternitive I'm thinking about using since I already have library that's access that endpoint through OkHttpClient.

Mono blockingWrapper = Mono.fromCallable(() -> { 
    return /* make a remote synchronous call */ 
});
blockingWrapper = blockingWrapper.subscribeOn(Schedulers.boundedElastic());

Answer 1

When you use reactor in a non-webflux application, for instance using the WebClient in a regular spring web application the reactor framework will start up a single event loop to handle all the events scheduled by the schedulers.

If you on the other hand run a WebClient in a fully reactive webflux application, the underlying server will start up as many event loops as there are cores on the host.

Now that we know that, lets start with your examples.

Spring WebClient

If you use this, the framework will start up a scheduler with a thread pool, and it can whenever it want switch scheduling thread freely. It might schedule the flapMap using one thread, calling the rest api using another scheduling thread, it can switch as it wants. When you block or subscribe, you leave the threading to the framework and it will optimize as much as it can, with what it has.

Wrapping blocking calls

If you on the other hand wrap a blocking call using a onSubscribe you are basically saying when someone subscribes (or blocks) pick a single thread from the defined scheduler and use that thread all through out execution to schedule events on the event loop.

So what you end up getting is basically the same standard behavior that a regular servlet application has.

My personal opinion is to use webclient because reactor is made to basically abstract away the threading from you so it can do its thing as good as possible and you can focus on dealing with the business logic instead. You basically pick reactive programming to get highly optimized async non-blocking code as simple as possible without needing to deal with async annotations, locks, latches, futures, thread pools, etc.