What is Spring Cloud Gateway?

Hello everyone. This article is a continuation of the previous article

If you have not read it, please read that and come back here to have a continuation.

Spring Cloud Gateway is an API Gateway / Backend For the FrontEnd (BFF) framework. It is based on Spring 5, Spring Boot 2, and Project Reactor / Webflux and works on a non-blocking API model. Basically, it is a Spring Webflux application and I will write another article on Spring Webflux to explain it in depth.

When using a non-blocking API model, a thread is always available to process the incoming request. These requests are then processed asynchronously in the background and once completed the response is returned.

This will save a lot of overhead compared to the traditional blocking servers where all the incoming requests will be waiting until the response. These are the following dependencies required to build a Spring Cloud API Gateway application.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

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

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka- client</artifactId>
</dependency>

The Spring Cloud Gateway uses Netty as the embedded server instead of the Tomcat server because Tomcat is based on the blocking model and Netty is based on the non-blocking model.

The functionality of Spring Cloud Gateway

• Built on Spring framework 5, project reactor and Spring Boot 2.0
• Able to match routes on any requested attribute
• Predicates and filters are specific to routes
• Circuit Breaker integration
• Spring Cloud Discovery Client integration
• Easy to write Predicates and filters
• Request Rate Limiting
• Path rewriting
• Spring Security Integration

Spring Cloud gateway works very well with the Spring ecosystem and is an obvious choice for the microservices developed using the Spring framework. Moreover, it acts as a single facade layer to any type of client like mobile, web, etc.

As seen from the above diagram, all the front-end clients talk to a single component and Spring Cloud Gateway takes care of routing the request to the respective microservice and gets the response to the client. In a cloud environment, Spring Cloud Gateway runs in the Public subnet (public IP) and all other microservices run in the private subnet (private IP).

Spring Cloud gateway is also a discovery client along with other microservices and hence it discovers the microservice from the service discovery registry and routes to those services using its private IP. By doing so, we are reducing the risk of exposing the entire microservices architecture to the public.

Spring Cloud Gateway can also handle Authentication and Authorization. Authentication is done by integrating Spring Security. Authorization of the JWT tokens can be done here at a centralized place thereby reducing the overhead for every other microservice.

We can also route in the RouteLocator bean java file or as the configuration in the property file. These routes will decide where to send the request when the incoming request pattern is matched. For every request, rate limiters can be applied specifically as well.

Global Filters — Pre and Post Filter

Global filters are executed for every route defined in the API Gateway. The main difference between pre-filter and post-filter classes is that the pre-filter code is executed before Spring Cloud API Gateway routes the request to a destination web service endpoint.

While the post-filter code will be executed after Spring Cloud API Gateway has routed the HTTP request to a destination web service endpoint. Pre-Filter is usually used to do some Authentication / Authorization for all requests before they are routed to the specific microservice. Post-Filter is used to alter the response like decorating the response and send to the front end.

What is Backend for FrontEnd (BFF) Pattern?

The BFF is a design pattern by which every client will talk to its own API gateway instead of the common gateway. In the diagram above, there is a single Spring Cloud API gateway application that is shared by three different clients namely IoT, Mobile, and Web.

If we use a specific API Gateway for each of these clients, then there will be different Gateway applications running in the public subnet. These API gateways are collectively called Backend for FrontEnd

AWS API Gateway vs Spring Cloud Gateway

There are a lot of API gateways available in the market like Spring Cloud API Gateway, Zuul 2, Apigee, Kong, AWS API Gateway and so on. But I would like to answer the commonly asked question. Which one I should use AWS API Gateway or Spring Cloud Gateway?

The answer is

Use AWS API Gateway if you need following

• Serverless Infrastructure
• Easy and quick to deploy APIs
• Simple Routing rules
• Quicker Request Response

Use Spring Cloud Gateway for the following

• If you need granular control on your API Gateway
• If you want to add custom filters and complex routes
• If your API takes a long time to respond. AWS API Gateway will timeout if the response takes more than 29 seconds per request
• If you use the Spring ecosystem, Spring Cloud Gateway will fit in well

Please continue reading my following articles

If you like to get more updates from me, please follow me on Medium and subscribe to email alert. 

If you are considering to buy a medium membership, please buy through my referral link