The API Gateway Pattern in Microservices

An API Gateway acts as a proxy between the Client Apps and the microservices endpoints. I have explained in the previous article (Introduction to Microservices Architecture), that each microservice exposes a set of fine-grained endpoints. Each of these services can be hosted on a different server, hence exposing different host URLs. In this article, we will explore the need for API Gateway and its significance in the microservices world.

1. Direct Client to Microservices communication

Let us say we have our Angular UI deployed in Apache on https://my-shop.com, Inventory services on https://my-shop.com/inventory, shipping service at https://my-shop.com/shipping and similarly account service at https://my-shop.com:9990/payment. Since we do not know what is an API Gateway, our client app (Angular app from Browser) will communicate directly with each of these services.

It is not necessary that all the microservices will have public endpoints, for simplicity we have considered so. The Direct communication architecture can be good for a small application, especially when you have a small UI and a couple of different Backend services. However, this has a ton of limitations when you build complex and large applications and the UI is like a Mobile app.

1.1. Limitations:

• Cross-cutting Concerns: Each public-facing microservice has to handle concerns like SSL, authentication and authorization, data transformations, rate limiting, etc. Using a Gateway can help in reducing the overhead, as all of this can be addressed on it and the microservices endpoints are never directly exposed to the outside world.

• Larger Security Concerns: Without the Gateway, all the microservices are exposed to the external world. An attacker has a wider surface to attack and get inside the system. However, using a gateway, only the gateway URL is exposed so we have a smaller surface to secure.

• Tight Coupling: The micro-services endpoints should never be hardcoded in the UI apps, be it Mobile or Web. Refactoring or adding a new service will need the URL changes in the client apps and hence maintenance overheads. Frequently updating apps will bring the solutions to evolve fast.

• Impact on User Experiences: Using an API gateway, we can possibly reduce the multiple service calls by aggregating the payload and serving them once. This can improve user performance by reducing the waiting time. However, this topic is debatable.

2. What is an API Gateway Service

An API Gateway is a special service that stays between the client apps and microservices. It behaves like a reverse proxy and routes the client requests to the correct microservices. In addition to this, it also provides other cross-cutting features such as authentication, SSL, cache, rate limiting, etc.

When we design a large and complex microservices-based architecture, we need to consider the API Gateway. There can be a Single API Gateway or Several API Gateway depending upon the complexity of the application.

2.1. Using a Single API Gateway

For a comparatively small/medium scale application, you can have a single API Gateway. It acts as a single communication point for all your frontend API requests and the gateway forwards the API requests to respective microservices. You need to be careful not to use the single API Gateway as a Monolithic Orchestrator, which can lead to a single point of failure.

It is recommended to Split the API Gateway into multiple services, for example, one per client-app type. It can also be segregated based on business boundaries. The idea is to not use it as a typical monolithic Orchestrator.

2.2. Using Multiple API Gateways

When you use multiple API Gateways based on the type of client apps, this pattern is named “Backend for Frontend” (BFF). Each API Gateway can be tailored to meet the specific cross-cutting concerns of each client type.

Most importantly, by using the multiple API Gateways we will avoid the single point of failure. The below picture is an example of how we can split the gateway, however, it can be split based on several business logics.

3. Important features of API Gateway pattern

• Reverse proxy capability and request routing:
  An API Gateway has to work as a reverse proxy in forwarding or routing the coming requests to the correct microservices endpoints. It provides a single endpoint to the Client app to simplify communications. The Gateway also helps in decoupling the microservices from the Client apps.

• Reduces the number of Request/response roundtrips:
  This concept is often referred to as Requests Aggregation. API gateway often needs to combine multiple client requests targeted for multiple internal microservices into a single client request. This helps in reducing the API request/response time and hence the User Experiences. It can be configured to provide optimal API to each client.

• Monolith Strangling:
  Often monolith Services are plugged behind gateways along with other microservices. This helps the developers to gradually refactor the monolith services at a comfortable pace.

• Resiliency:
  Gateway is the front-face of all Backend services, any error that occurs in any of the microservices can be handled better by it. We can also have a smart retry or routing policy based on the error events so that the end-user experiences are not affected.

• Address the Cross-cutting concerns:
  • Authentication and authorization
  • Monitoring
  • Load balancing and Canarying (route to a specific instance based on certain properties.)
  • Payload response caching
  • Rate limiting, IP allow-listing/block-listing
  • Service discovery
  • Logging, Tracing, and Correlation

• Additional complexity to the architecture.
• Can lead to a single point of failure if not thought out well.
• It usually increases the API response time due to the additional network routing. However, this is less impact as compared to the complexity of the problem it tries to solve.
• Additional development and maintenance costs.

4. Open Source API Gateways

There are quite a few open-source API Gateway products available, they offer way more feature because of which some of them can be called API Gateway management tools. I have just listed them here without much inside.

4.1. Tyk API Gateway

4.2. Kong API Gateway

4.3. KrakenD – fastest api gateway

4.4. Spring Cloud Gateway

This is the Gateway that you will learn in this tutorial series. This project is built on top of Spring Ecosystems like Spring Webflux, Project Reactor, and Spring Boot 2. It allows you to effectively route to APIs and provide cross-cutting concerns like security, monitoring, resiliency, etc.

5. Limitations of the Gateway pattern

There are a few potential limitations of using a Gateway in your microservices, but they are very small as compared to the purpose it tries to serve.

• Potential Single point of failure: Gateway is tightly coupled with the backend micro-services, it needs to be designed carefully so that you do not have a single point of failure in a hard time.

• Potential development bottleneck: When a new micro-service is developed, the existing API Gateway may need to be updated and redeployed. This can become a development bottleneck for the entire project. Important to keep the CI/CD Process in place and also keep this a lightweight process.

• Additional cost for development and future maintenance.

• An increase in the response time is due to the additional network layer.

6. Further references:

• Choosing the Right API Gateway Pattern for Effective API Delivery
• Pattern: API Gateway / Backends for Frontends
• GOTO 2020 • The Past, Present, and Future of Cloud-Native API Gateways by Daniel Bryant
• Living on the Edge with Spring Cloud Gateway
• The API gateway pattern versus the Direct client-to-microservice communication