DEV Community: Ilkin

What is API Gateway exactly? Spring Cloud Gateway?

Ilkin — Sun, 03 Mar 2024 20:57:21 +0000

What is an API Gateway?
Simple Example for API Gateway
Spring Cloud Gateway
API GW example with Spring Cloud Gateway
- JAVA API
- Dynamic Routing

What is an API Gateway?

An application programming interface (API) gateway functions as a reverse proxy to receive all API calls, aggregates the services needed to fulfill them, and returns the appropriate result.
All that clients must know is how to get to the API gateway. A consistent and steady point of access is provided by the
API gateway, regardless of the offline status, or instability of the backend services.

An API gateway not only services requests but also provides functionality to return requested data as the client's
needs. Before forwarding an API request to the API endpoint for processing, an API gateway can apply the necessary pre and/or
post-processing filters such as Single Sign-On (SSO), rate limiting, request validation, and tracing. An API gateway offers all these features and more, making APIs easier to maintain,
secure, and design and use.
At the end of the day, an API gateway simplifies external access and reduces communication complexity between
microservices by acting as a single point of entry for several backend APIs.

Simple Example for API Gateway

The below diagram shows a simple and common way to use an API gateway:

Let's break down this graph. The client wants to get all his Orders from the service and requests /getOrder API.
Client only knows this '/getOrder' and does not have any idea and access to all the rest services.

First of all, we need to authenticate the user, let's think that we are using JWT for authentication. As soon as API GW
receives the request(/getOrder), it tries to find the user and
authenticate it to find whether the user has access to the specified API or not. So we are getting a JWT token from the
header in API GW, and Requesting to AUTH service. AUTH service will decode JWT and request USER info, at the end of the auth flow, the AUTH service will return user access from the AUTH service and if the user has it, user info from the USER service. The second step will be returning the real requested data to the client, which is '/getOrder'. API GW starts to communicate to the ORDER service and returns the requested data.
Even though we have communicated with API GW, AUTH, USER, ORDER services separately. The user only aware of 1
endpoint and do not have any idea of what or how we authenticate and return data. As from this example, API GW is a single-point
of entry for the client.

Spring Cloud Gateway

As the number of Microservices grows, the need for creating a gateway also increases. Modern Spring Cloud project also
introduced API gateway solution for the Spring echo
system, Spring Cloud Gateway:

This project provides libraries for building an API Gateway on top of Spring WebFlux or Spring WebMVC. Spring Cloud
Gateway aims to provide a simple, yet effective way to route to APIs and provide cross-cutting concerns to them such
as security, monitoring/metrics, and resiliency.

This project is not only used for Gateway but also as a BFF framework(Backend for Frontend).
It operates on a non-blocking API model and is built on Spring 5, Spring Boot 2, and Project Reactor / Webflux.

This project provides an API Gateway built on top of the Spring Ecosystem, including Spring 5, Spring Boot 2 and
Project Reactor.

Due to reactivity, it comes with Netty instead of Tomcat as a web server. In some cases, it might create ambiguity/issues when used with other Spring services.

Even though this project focuses on the reactive server, there's an option to include a Servlet-based MVC and a non-reactive version of this project.

Spring Cloud GW provides all the necessary tools from out-of-box to create a GW. We have 2 options for creating and
managing our Gateway.
Java API and Dynamic Routing. Yes, this project not only provides Java APIs for creating our gateway with Java code but
also we can create everything that we did with Java API with a simple YAML file. with this magic, we even do not have to know
JAVA or SPRING to some extent. Let us continue with the above example.

API GW example with Spring Cloud Gateway

What we will try to build is a simple Order/Product microservices, we will focus on 2 APIs:
/getProducts and makeOrder

We have 2 microservices Orders and Products, and 2 API endpoints respectively: /orders and /products.
The client is aware of 2 APIs: orders/makeOrder and products/getProducts.

JAVA API

Let's start with Gateway. First, we will build with a Java API approach. Gateway is a lightweight, reactive(Netty-based), and simple Java app. Gateway consist of routes, predicates and
filters to customize these routes.

We create a custom Config class to apply our customizations. The project provides us with a special Bean - RouteLocator to
easily configure our all incoming HTTP requests.
This will be our main entry point for request locating.

    @Bean
    public RouteLocator gatewayRoutes(RouteLocatorBuilder routeLocatorBuilder) {
        return routeLocatorBuilder
                .routes()
                .route(
                        ConfigurationConstants.AUTH_SERVICE_ID,
                        getRoute(ConfigurationConstants.AUTH_SERVICE_ROOT, msAuthRoot))
                .route(
                        ConfigurationConstants.PRODUCT_SERVICE_ID,
                        getRoute(ConfigurationConstants.PRODUCTS_SERVICE_ROOT, msProductRoot))
                .route(
                        ConfigurationConstants.ORDER_SERVICE_ID,
                        getRoute(ConfigurationConstants.ORDERS_SERVICE_ROOT, msOrderRoot))
                .build();
    }

When we are building RoutLocate we are providing the route() method, which will accept ID for the route and a Function
to apply all necessary changes to the route. Below is a custom method to make it easier and more reusable route function.


    private Function<PredicateSpec, Buildable<Route>> getRoute(String root, String uri) {
        return r ->
                r.path(root.concat("/**"))
                        .filters(filterSpec -> getGatewayFilterSpec(filterSpec, root))
                        .uri(uri);
    }

    private GatewayFilterSpec getGatewayFilterSpec(GatewayFilterSpec f, String serviceUri) {
        return f.rewritePath(
                        serviceUri.concat("(?<segment>.*)"), API_V1.concat(serviceUri).concat("${segment}"))
                .filter(jwtAuthenticationFilter);
    }

What we are passing to this routing method is root (e,g /products) and actual URI (e,g localhost:8082). What it means,
when Client execute an API call to any endpoint(let assume our /products/getProducts) with '/products' root, first we
are concatenating the path from the root (we are getting everything after root which is '/getProducts') and we are replacing the root with our internal API which is (e,g localhost:8082).

So when we are finishing request, client root + '/products/getProducts' became internally server root + '
/api/v1/products/getProducts'.

The final version of the Config class:


@Slf4j
@RequiredArgsConstructor
@Configuration
public class GatewayConfig {
    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Value("${ms.product.root}")
    private String msProductRoot;

    @Value("${ms.auth.root}")
    private String msAuthRoot;

    @Value("${ms.order.root}")
    private String msOrderRoot;

    @Bean
    public RouteLocator gatewayRoutes(RouteLocatorBuilder routeLocatorBuilder) {
        return routeLocatorBuilder
                .routes()
                .route(
                        ConfigurationConstants.AUTH_SERVICE_ID,
                        getRoute(ConfigurationConstants.AUTH_SERVICE_ROOT, msAuthRoot))
                .route(
                        ConfigurationConstants.PRODUCT_SERVICE_ID,
                        getRoute(ConfigurationConstants.PRODUCTS_SERVICE_ROOT, msProductRoot))
                .route(
                        ConfigurationConstants.ORDER_SERVICE_ID,
                        getRoute(ConfigurationConstants.ORDERS_SERVICE_ROOT, msOrderRoot))
                .build();
    }

    private Function<PredicateSpec, Buildable<Route>> getRoute(String root, String uri) {
        return r ->
                r.path(root.concat("/**"))
                        .filters(filterSpec -> getGatewayFilterSpec(filterSpec, root))
                        .uri(uri);
    }

    private GatewayFilterSpec getGatewayFilterSpec(GatewayFilterSpec f, String serviceUri) {
        return f.rewritePath(
                        serviceUri.concat("(?<segment>.*)"), API_V1.concat(serviceUri).concat("${segment}"))
                .filter(jwtAuthenticationFilter);
    }
}

That's it, this is pretty much how we handle the Gateway mechanism with Spring Cloud Gateway. But from the graph and API
gateway section, we also discussed Authentication.
We will create a JwtAuthenticationFilter, we will mock it instead of applying real implementation. before we rewrite our HTTP path, we can apply as many custom filters as we want.

This is simply a reactive WebClient-based Auth implementation, To apply a Gateway filter we need to implement specific interface, GatewayFilter.

@Slf4j
@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter implements GatewayFilter, Ordered {
  @Value("${security.auth.url}")
  private String authServiceBase;

  @Value("${security.auth.introspect-api}")
  private String authServiceIntrospect;

  @Override
  public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    ServerHttpRequest request = exchange.getRequest();

      WebClient webClient = WebClient.builder().baseUrl(authServiceBase).build();

      return webClient
          .get()
          .uri(authServiceIntrospect)
          .retrieve()
          .bodyToMono(Boolean.class)
          .flatMap(
              credentials -> {
                log.info("Starting authentication, ACCESS: {}", credentials);
                return chain.filter(exchange);
              })
          .onErrorResume(
              ex -> onError(exchange, "Failed to authenticate token.", HttpStatus.UNAUTHORIZED));
  }

  private Mono<Void> onError(ServerWebExchange exchange, String err, HttpStatus httpStatus) {
    log.error("ERROR ON CALL: {}", err);
    exchange.getResponse().setStatusCode(httpStatus);
    exchange.getResponse().getHeaders().set(HttpHeaders.CONTENT_TYPE, "text/plain");
    return exchange
        .getResponse()
        .writeWith(Mono.just(exchange.getResponse().bufferFactory().wrap(err.getBytes())));
  }


  @Override
  public int getOrder() {
    return -1;
  }

So what is happening, basically, in every Client call, we are always adding this JwtFilter, as we are doing in
traditional SpringSecurity. In this API call, we are calling the Auth microservice with WebClient, for the simplicity we are just returning a 'true' as access granted in every request, this is the AuthController:

@Slf4j
@RestController
@RequestMapping("/api/v1/auth")
public class AuthController {
    @GetMapping("/introspect")
    public ResponseEntity<Boolean> hasAccess(){
        log.info("Starting to AUTH process...");
        return ResponseEntity.ok(Boolean.TRUE);
    }
}

We have Custom Routing, Flexible and reactive authentication, and a lightweight Spring app. We have implemented our drawing into code.

Dynamic Routing

I have mentioned a dynamic way to create these routers as well. It compiles to the same Java code, but this is the simple version of our routing class as a dynamic version:

spring:
  application:
    name: gateway-service
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: http://localhost:8082
          predicates:
            - Path=/orders/**
          metadata:
            response-timeout: 200
            connect-timeout: 200
        - id: product-service
          uri: http://localhost:8083
          predicates:
            - Path=/product/**
          metadata:
            response-timeout: 400
            connect-timeout: 400

From the above YAML file, we can see we have created 2 Route, for each route we are giving uri, and Predicate which will
be listened to capture requests. This Predicate can be customized based on app needs, or we can listen to query params as well. We can add metadata, I have added custom response and connect/timeout parameters for each Route in the example. This is just one of the Predicate/Filters, there's much more such as custom Circuit Breaker, Caching (With Redis as well), fallback URI, route-based Load Balancing, etc. Please check the official Spring documentation for the full details.

Results of our Gateway:

Internal products endpoint: localhost:8082/api/v1/products/getProducts

Internal orders endpoint: localhost:8083/api/v1/orders/makeOrder

Conclusion

In this article, we talked about what is API Gateway, what is the common use case and why we need it. We talked about modern Spring Cloud project - Spring Cloud Gateway, which provides a simple, easy-to-use, and customizable way to create our Gateway.

API gateway is a single point of entry for our application and all microservices. It makes not only routing easier but also we can make a single point for a common request/response model for the client. We can authenticate/validate our requests before routing them to our microservices, with that our services load will be much less, and they won't accept unrelated requests anymore. We can also include CircuitBreaker pattern and prevent API abuse for our endpoint, also Caching is a commonly used way for Gateways and much more.

Nevertheless, we must not forget that, by introducing a Gateway, whether Spring Cloud or not, we are introducing an additional
layer between the Client and our APIs, so with that, we have some tradeoffs as well, such as, we will get some response time gain due to an additional HTTP layer. As I mentioned, Gateway is a single point of entry, so it means we are creating a single point of failure as well, In case of Gateway is down, regardless of our other services, we will be unavailable at all. So Gateway becomes additional responsibility for the server.

If we need to add custom filters to our routes, customize our routes, already have Spring ecosystem, and If APIs require more precise control API Gateway and Spring Cloud Gateway are very good choices and easy to pick up.

The example project presented here can be found in
my GitHub repository.

Understanding @Async in Spring Boot

Ilkin — Mon, 29 Jan 2024 09:18:11 +0000

Asynchronous approach

With the high development of hardware & software, modern applications become much more complex and demanding. Due to
high demand engineers always try to find new ways to improve their application performance and responsiveness. One solution to slow-paced applications is the implementation of the Asynchronous approach. Asynchronous processing is a technique that is a process or function that executes a task to run concurrently, without waiting for one task to complete it before starting another. In this article, I will try to explore the Asynchronous approach and @Async annotation in Spring Boot, trying to explain the differences between multi-threading and concurrency, and when to use or avoid it.

Asynchronous approach
Table of contents
What is @Async in Spring?
How is @Async different from multithreading and Concurrency?
When to use @Async and when to avoid it.
Using @Async in a Spring Boot application.
Conclusion

What is @Async in Spring?

The @Async annotation in Spring enables asynchronous processing of a method call. It instructs the framework to execute the method in a separate thread, allowing the caller to proceed without waiting for the method to complete. This
improves the overall responsiveness and throughput of an application.

To use @Async, you must first enable asynchronous processing in your application by adding the @EnableAsync annotation
to a configuration class:

@Configuration
@EnableAsync
public class AppConfig {
}

Next, annotate the method you want to execute asynchronously with the @Async annotation:


@Service
public class AsyncService {
    @Async
    public void asyncMethod() {
        // Perform time-consuming task
    }
}

How is @Async different from multithreading and Concurrency?

Sometimes It might seem confusing to differentiate multithreading and concurrency from parallel execution, however, both are related to parallel execution. Each of them has their use case and implementation:

@Async annotation is Spring Framework-specific abstraction, which enables asynchronous execution. It gives the ability to use async with ease, handling all hard work in the background, such as thread creation, management, and execution. This allows users to focus on business logic rather than low-level details.
Multithreading is a general concept, commonly referring to the ability of an OS or program to manage multiple threads concurrently. As @Async helps us to do all hard work automatically, in this case, we can handle all this work manually and create a multithreading environment. Java has necessary classes such as Thread and ExecutorService to create and work with multithreading.
Concurrency is a much broader concept, and it covers both multithreading and parallel execution techniques. It is the
ability of a system to execute multiple tasks simultaneously, on one or more processors across.

In summary, @Async is a higher-level abstraction that simplifies asynchronous processing for developers, on the other hand, multithreading and concurrency are more about to manual management of parallel execution.

When to use @Async and when to avoid it.

It seems very intuitive to use an asynchronous approach, however, it must be taken into account, there's do's and don'ts for this approach as well.

Use @Async when:

You have independent, time-consuming tasks that can run concurrently without affecting the application's responsiveness.
You want a simple and clean way to enable asynchronous processing without diving into low-level thread management.

Avoid using @Async when:

The tasks you want to execute asynchronously have complex dependencies or need a lot of coordinating. In such cases, you might need to use more advanced concurrency APIs, like CompletableFuture, or reactive programming libraries like Project Reactor.
You must have precise control over how threads are managed., such as custom thread pools or advanced synchronization mechanisms. In these cases, consider using Java's ExecutorService or other concurrency utilities.

Using @Async in a Spring Boot application.

In this example, we will create a simple Spring Boot application that demonstrates the use of @Async.
Let's create a simple Order management service.

Create a new Spring Boot project with minimum dependency requirements:

org.springframework.boot:spring-boot-starter
org.springframework.boot:spring-boot-starter-web
Web dependency is for REST endpoint demonstration purpose. @Async comes with boot starter.
Add the @EnableAsync annotation to the main class or Application Config class, if we are using it.:

@SpringBootApplication
@EnableAsync
public class AsyncDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(AsyncDemoApplication.class, args);
  }
}

@Configuration
@EnableAsync
public class ApplicationConfig {}

For the optimal solution, what we can do is, create a custom Executor bean and customize it as per our needs in the same Configuration class:

   @Configuration
   @EnableAsync
   public class ApplicationConfig {

     @Bean
     public Executor getAsyncExecutor() {
       ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
       executor.setCorePoolSize(5);
       executor.setMaxPoolSize(10);
       executor.setQueueCapacity(100);
       executor.setThreadNamePrefix("AsyncThread-");
       executor.initialize();
       return executor;
       }
   }

With this configuration, we have control over max and default thread pool size. As well as other useful customizations.

Create an OrderService class with @Async methods:

@Service
public class OrderService {

  @Async
  public void saveOrderDetails(Order order) throws InterruptedException {
    Thread.sleep(2000);
    System.out.println(order.name());
  }

  @Async
  public CompletableFuture<String> saveOrderDetailsFuture(Order order) throws InterruptedException {
    System.out.println("Execute method with return type + " + Thread.currentThread().getName());
    String result = "Hello From CompletableFuture. Order: ".concat(order.name());
    Thread.sleep(5000);
    return CompletableFuture.completedFuture(result);
  }

  @Async
  public CompletableFuture<String> compute(Order order) throws InterruptedException {
    String result = "Hello From CompletableFuture CHAIN. Order: ".concat(order.name());
    Thread.sleep(5000);
    return CompletableFuture.completedFuture(result);
  }
}

What we did here is create 3 different Async methods. First saveOrderDetails service is a straightforward asynchronous
service, which will start doing the computing asynchronously. If we want to use modern asynchronous Java features
like CompletableFuture, we can achieve it with saveOrderDetailsFuture service. With this service, we can call a thread to wait for the result of an @Async. It should be noted that CompletableFuture.get() will block until the result is available. If we want to perform further asynchronous operations when the result is available, we can use thenApply, thenAccept, or other methods provided by CompletableFuture.

Create a REST controller to trigger the asynchronous method:

@RestController
public class AsyncController {

 private final OrderService orderService;

  public OrderController(OrderService orderService) {
    this.orderService = orderService;
  }

  @PostMapping("/process")
  public ResponseEntity<Void> process(@RequestBody Order order) throws InterruptedException {
    System.out.println("PROCESSING STARTED");
    orderService.saveOrderDetails(order);
    return ResponseEntity.ok(null);
  }

  @PostMapping("/process/future")
  public ResponseEntity<String> processFuture(@RequestBody Order order) throws InterruptedException, ExecutionException {
    System.out.println("PROCESSING STARTED");
    CompletableFuture<String> orderDetailsFuture = orderService.saveOrderDetailsFuture(order);
    return ResponseEntity.ok(orderDetailsFuture.get());
  }

  @PostMapping("/process/future/chain")
  public ResponseEntity<Void> processFutureChain(@RequestBody Order order) throws InterruptedException, ExecutionException {
    System.out.println("PROCESSING STARTED");
    CompletableFuture<String> computeResult = orderService.compute(order);
    computeResult.thenApply(result -> result).thenAccept(System.out::println);
    return ResponseEntity.ok(null);
  }
}

Now, when we access the /process endpoint, the server will return a response right away, while
the saveOrderDetails() continues to execute in the background. After 2 seconds, the service will complete. Second endpoint - /process/future will use our second option which is CompletableFuture In this case after 5 seconds, the service will complete, and store the result in CompletableFuture we can further use future.get() to access the result. In the last endpoint -/process/future/chain, we optimized and used asynchronous computations. Controller using the same service method for CompletableFuture, however right after the future, we are using thenApply, thenAccept methods. The server returns a response right away, we do not need to wait for 5 seconds, and computation will be done background. The most important point, in this case, is a call to async service, in our case compute() must be done from the outside of the same class. If we use @Async on a method and call it within the same class, it won't work. This is because Spring uses proxies to add asynchronous behavior, and calling the method internally bypasses the proxy. To make it work, we can either:

Move the @Async methods to a separate service or component.
Use ApplicationContext to get the proxy and call the method on it.

Conclusion

The @Async annotation in Spring is a powerful tool for enabling asynchronous processing in applications. By using @Async, we don't need to go into the complexities of concurrency management and multithreading to enhance the responsiveness and performance of our application. But to decide when to use @Async or go with alternative concurrency
utilities, it's important to know its limitations and use cases. This is the link for the project used on this blog.

You can check my blog website as well: https://blog.ilkinmehdiyev.com/posts/understanding-async-java

DEV Community: Ilkin

What is API Gateway exactly? Spring Cloud Gateway?

Table of contents

What is an API Gateway?

Simple Example for API Gateway

Spring Cloud Gateway

API GW example with Spring Cloud Gateway

JAVA API

Dynamic Routing

Conclusion

Understanding @Async in Spring Boot

Asynchronous approach

Table of contents

What is @Async in Spring?

How is @Async different from multithreading and Concurrency?

When to use @Async and when to avoid it.

Using @Async in a Spring Boot application.

Conclusion