API Gateway Design Pattern
When you want to develop a cloud-native application, your applications must be microservice-based and can be exposed with APIs. When the number of your microservices increases in the future, it will be difficult to manage APIs separately for each microservice. Integrating advanced options like authentication, security, authorization will result in both development effort and management overhead.
For this reason, it is preferred to manage APIs from a central point in large applications that have a large number of microservices.
Thanks to API Gateway technology, API management can be done easily from a central point.
In this article, I will try to explain the API gateway technology in detail. Let’s start with basic overview..
API gateway is a single entry point for backend APIs and microservices. These elements can be internal or external.
With this single entry point, you can apply security and authorization best practises, and also you can have scalability and high availability. API Gateway sits between a client and backend services. It works like a reverse proxy to accepts all API calls. It’s suitable for integrating legacy applications. You can also use it for building serverless applications.
This is a basic description of API Gateway. Before digging into it we need to understand the communication of microservice-based applications without API Gateway.
So let’s start with the client to microservice communication pattern first.
Client-to-microservice direct communication
This communication approach can fit small microservice-based applications with a few endpoints to interact with. If the number of microservices increases, this communication will start to be a problem.
If you prefer this approach,
- Each microservice will have a public endpoint.
- Different TCP ports will be required by microservices.
- There will be complex communication if the number of endpoint increase.
if you have a complex microservice-based application and if the client apps are mobile apps or single-page web applications you can have a few problems with this approach.
In client-to-microservice communication, there can be load-balancers between microservices and clients to distribute traffic to the microservices. These load balancers can be L7 or L3.
To reduce CPU usage of SSL termination and routing staff you can use an L7 load balancer.
When you decide to use this communication pattern with your applications you should take the questions below into consideration for the future;
How do differentiate APIs for a different types of clients?
The endpoints provided by microservices couldn’t be fit for a different types of clients. The requirements of mobile apps can be different from web apps. So the responses need to be optimized for client types. In that kind of situation, you need to position an API gateway between clients and microservices.
How to handle authorization, security and data transformation for all microservices?
It is hard to handle these requirements on each microservices. So it would be better to keep all microservices in a private docker or Kubernetes environment. All these requirements should be handled on a central point like API Gateway.
How to manage request count when the number of microservices increases?
The server-side should return an aggregated response to the client-side in such a case. it decreases the latency. So you have to position an API gateway in front of your microservices.
How do your client applications interact with services which used non-internet-friendly ports? (Like AMQP)
All requests that come from the client-side should use HTTP or HTTPS to interact with services and transform to accepted protocols. API gateway is a good option to handle this transformation process.
If you have any concerns about the questions above for future requirements you should consider using API Gateway in your infrastructure. Because probably you will have the problems like below;
- Client apps coupled with the microservices, maintenances will be hard.
- There will be too many round trips between client & server
- All microservices will be public. There will be a lot of attack surfaces.
- All Authorization & SSL requirements should be handled on the microservices side. So there will be lots of development effort
API Gateway pattern
If you want to design an application that includes many different client types and consists of many microservices, it is necessary to position the API gateway within the architecture. With the API gateway pattern, a single entry point for a complex application is integrated into the front of the application.
The API gateway is located between the client-side and the microservices and works as a kind of reverse proxy. It routes incoming requests to the microservices on its back.
In addition, there are advanced configuration options (known as cross-cutting features in some sources) such as authentication, SSL termination, and cache.
It is recommended to locate the API Gateway more than once, depending on the size of the application and the variety of client types. Positioning a single API Gateway in front of all microservices will cause a coupling problem. It’s not a good idea to have a single aggregator in front of the microservices. This is against the nature of the microservice architecture.
What are these advanced features?
Offloading:
Thanks to the advanced features offered by API gateway, you can transfer these functions to the API gateway from the microservice side. So such requirements are handled at a single point. In addition, the development effort required to integrate these features for each microservices is eliminated.
Offload Features:
- Authentication & Authorization
- Caching
- Rate limiting & throttling
- Ip whitelisting
- Retry rules
- Data transformations
Reverse Proxy:
API gateway receives HTTP requests from clients at layer 7 and forwards them to microservices. Clients access microservices via a single URL. In this way, it is ensured that the client-side and microservices are decoupled. When it is necessary to continue communication with monolithic APIs during application modernization, the client-side integrates with these legacy APIs thanks to the API Gateway. After the development of new microservices, monolithic structures are disabled with a simple traffic routing. In such transitions, since the API Gateway is positioned between the client and the services, the client-side is not affected in any way by these transactions.
Request Aggregation:
With this feature, multiple client requests that will call many microservices are collected in a single client request. This approach is usually used when the client-side will pull data from multiple microservices. For example, with this approach, a single request from the client is directed to more than one microservice, and the incoming responses are collected and directed to the client application. It is important to use this feature in mobile applications and single-page web applications that use javascript.
Are there some cons to using API Gateway?
- There will be a learning curve for both the infra and development sides.
- API Gateway will be the single point between frontend and backend services. So it can be affected via single-point failure. (So you need to consider high availability options)
- The application contains additional layers so it will bring difficulty for developers.
- Performance should be a concern. Because API gateway needs to handle every request. If the load size is increased it affects the speed and reliability of the application. So you need to consider scaling of the API Gateway layer.
- There will be an additional network layer which will be the cause of increased response time.
Conclusion
In cloud-native architectures, APIs are the way of communication. If this layer’s complexity increased (related to the number of microservices endpoints) it wouldn’t be easy to manage this communication. The API Gateway is the way of simple management of APIs.
Resources:
