Spring Boot FeignClient vs. WebClient

1. Overview

In this tutorial, we’ll compare the Spring Feign — a declarative REST client, and the Spring WebClient — a reactive web client introduced in Spring 5.

2. Blocking vs. Non-Blocking Client

In today’s microservice ecosystems, there’s usually a requirement for backend services to call other web services using HTTP. So, Spring applications need a web client to perform the requests.

Next, we’ll examine the differences between a blocking Feign client and a non-blocking WebClient implementation.

2.1. Spring Boot Blocking Feign Client

The Feign client is a declarative REST client that makes writing web clients easier. When using Feign, the developer has only to define the interfaces and annotate them accordingly. The actual web client implementation is then provided by Spring at runtime.

Behind the scenes, interfaces annotated with @FeignClient generate a synchronous implementation based on a thread-per-request model. So, for each request, the assigned thread blocks until it receives the response. The disadvantage of keeping multiple threads alive is that each open thread occupies memory and CPU cycles.

Next, let’s imagine that our service is hit by a traffic spike, receiving thousands of requests per second. On top of that, each request needs to wait several seconds for an upstream service to return the result.

Depending on the resources allocated to the hosting server and the length of the traffic spike, after a while, all the created threads will start to pile up and occupy all allocated resources. Consequently, this chain of events will degrade the service’s performance and eventually bring the service down.

2.2. Spring Boot Non-Blocking WebClient

The WebClient is part of the Spring WebFlux library. It’s a non-blocking solution provided by the Spring Reactive Framework to address the performance bottlenecks of synchronous implementations like Feign clients.

While the Feign client creates a thread for each request and blocks it until it receives a response, the WebClient executes the HTTP request and adds a “waiting for response” task into a queue. Later, the “waiting for response” task is executed from the queue after the response is received, finally delivering the response to the subscriber function.

The Reactive framework implements an event-driven architecture powered by Reactive Streams API. And as we can see, this enables us to write services that perform HTTP requests with a minimal number of blocking threads.

As a result, WebClient helps us build services that perform consistently in harsh environments by processing more requests using fewer system resources.

3. Comparison Example

To see the differences between Feign client and WebClient, we’ll implement two HTTP endpoints that both call the same slow endpoint that returns a list of products.

We’ll see that in the case of the blocking Feign implementation, each request thread blocks for two seconds until the response is received.

On the other hand, the non-blocking WebClient will close the request thread immediately.

To start, we’ll need to add three dependencies:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

Next, we have the slow endpoint definition:

@GetMapping("/slow-service-products")
private List<Product> getAllProducts() throws InterruptedException {
    Thread.sleep(2000L); // delay
    return Arrays.asList(
      new Product("Fancy Smartphone", "A stylish phone you need"),
      new Product("Cool Watch", "The only device you need"),
      new Product("Smart TV", "Cristal clean images")
    );
}

3.1. Using Feign to Call a Slow Service

Now, let’s start implementing the first endpoint using Feign.

The first step is to define the interface and annotate it with @FeignCleint:

@FeignClient(value = "productsBlocking", url = "http://localhost:8080")
public interface ProductsFeignClient {

    @RequestMapping(method = RequestMethod.GET, value = "/slow-service-products", produces = "application/json")
    List<Product> getProductsBlocking(URI baseUrl);
}

Finally, we’ll use the defined ProductsFeignClient interface to call the slow service:

@GetMapping("/products-blocking")
public List<Product> getProductsBlocking() {
    log.info("Starting BLOCKING Controller!");
    final URI uri = URI.create(getSlowServiceBaseUri());

    List<Product> result = productsFeignClient.getProductsBlocking(uri);
    result.forEach(product -> log.info(product.toString()));

    log.info("Exiting BLOCKING Controller!");
    return result;
}

Next, let’s execute a request and see how the logs are looking:

Starting BLOCKING Controller!
Product(title=Fancy Smartphone, description=A stylish phone you need)
Product(title=Cool Watch, description=The only device you need)
Product(title=Smart TV, description=Cristal clean images)
Exiting BLOCKING Controller!

As expected, in the case of synchronous implementations, the request thread is waiting to receive all products. After, it’ll print them to the console and exit the controller function before finally closing the request thread.

3.2. Using WebClient to Call a Slow Service

Second, let’s implement a non-blocking WebClient to call the same endpoint:

@GetMapping(value = "/products-non-blocking", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<Product> getProductsNonBlocking() {
    log.info("Starting NON-BLOCKING Controller!");

    Flux<Product> productFlux = WebClient.create()
      .get()
      .uri(getSlowServiceBaseUri() + SLOW_SERVICE_PRODUCTS_ENDPOINT_NAME)
      .retrieve()
      .bodyToFlux(Product.class);

    productFlux.subscribe(product -> log.info(product.toString()));

    log.info("Exiting NON-BLOCKING Controller!");
    return productFlux;
}

Instead of returning the list of products, the controller function returns the Flux publisher and completes the method quickly. In this case, the consumers will subscribe to the Flux instance and process the products once they’re available.

Now, let’s look at the logs again:

Starting NON-BLOCKING Controller!
Exiting NON-BLOCKING Controller!
Product(title=Fancy Smartphone, description=A stylish phone you need)
Product(title=Cool Watch, description=The only device you need)
Product(title=Smart TV, description=Cristal clean images)

As expected, the controller function completes immediately, and by this, it also completes the request thread. As soon as the Products are available, the subscribed function processes them.

4. Conclusion

In this article, we compared two styles of writing web clients in Spring.

First, we’ve explored Feign client, a declarative style of writing synchronous and blocking web clients.

Secondly, we’ve explored WebClient, which enables the asynchronous implementation of web clients.

Although the Feign client is a great choice in many cases and the resulting code has lower cognitive complexity, the non-blocking style of WebClient uses much fewer system resources during high-traffic spikes. Considering this, it’s preferable to choose WebClient for those cases.