What is an API Gateway?
Understand what an API Gateway is, its use cases, and basic concepts for network routing and security.
An API Gateway is a reverse proxy that serves as a security barrier between your clients and the microservices that make up your app. In order to access a microservice, all clients must send a request to the API Gateway. The API Gateway then verifies and routes the request to the microservice.
How it works
To understand how an API Gateway works, let’s compare how clients send requests to microservices with and without an API Gateway.
Microservices architecture without an API Gateway
The following image shows two clients, a web and a mobile client, that users can use to view information about a product. To display the different components of the web or mobile page, the client must send a request to the corresponding microservice. For example, to see the details about a product, the client sends a request to the product details microservice. To list the number of products that are in stock, the client must call the inventory service, and so on.
As depicted in the image, to build the entire web page for the user, the client must send several requests to different microservices. To protect each microservice, you implement additional, non-business logic, such as external authentication and authorization, rate limiting, and SSL termination. This logic must be applied and maintained for each microservice. In addition, this setup requires all microservices to use a protocol that all clients support.
Microservices architecture with an API Gateway
Now take a look at how this setup changes when introducing an API Gateway. Instead of sending requests from the clients to each microservice, the API Gateway now serves as the main entrypoint for all client requests. Because all requests must go through the API Gateway, you can offload non-business logic, such as external authentication and authorization, from your microservices to the API Gateway. With this setup, you can use the Gateway to build a security barrier for your microservices and enforce the same security measures for your entire microservices architecture.
Benefits
Review what benefits an API Gateway can add to your microservices architecture.
| Benefit | Description |
|---|---|
| Offload non-business logic | Instead of adding non-business logic to each of your microservices, you can use the API Gateway to implement and enforce common security measures, such as external authentication and authorization, SSL termination, rate limiting, or mirroring for all of your microservices. All client requests must pass this additional security barrier before they are forwarded to your microservices. |
| Custom protocols | You can use an API Gateway to enforce HTTPS connections from the clients to the API Gateway. However, when forwarding the request from the API Gateway to the microservice, you can choose to use a different protocol, such as HTTP, to improve performance and request latency. This option enables you to use the protocol that best fits your microservice while maintaining a secure barrier for incoming requests. In addition, microservices that do not support an internet-friendly protocol can still be accessed by a client without the need to change the client behavior. |
| Improved client performance | API Gateways bundle the requests that need to be made to the individual microservices. For example, when accessing a web page, instead of calling each microservice, the client sends one request to the API Gateway. The Gateway then retrieves all the information for the page from the microservices and sends back the content to the client. This approach significantly decreases the number of requests that need to be made, and reduces request latency and UI complexity. |
| Protect microservices from external attacks | The API Gateway serves as a security barrier for your microservices that lets you enforce the same security measures across your entire microservices architecture. For example, you can use the API Gateway to enforce authentication and authorization for all clients and to only allow HTTPS connections from clients. |
| Routing and load balancing | The API Gateway serves as a router for all your microservices. You can configure the API Gateway to route requests to a specific microservice based on certain conditions, such as the client the request came from, and locality or availability of the target microservice. If multiple instances of your app exist, the API Gateway can load balance incoming requests between the instances. To enable canary deployments and A/B testing, you can also configure the API Gateway to route a subset of incoming request to a different version of your microservice. |
| Monitoring | Because all client requests are sent to the API Gateway, you can use it as a source to monitor incoming requests. For example, you can view the number of incoming requests and how many requests succeeded or failed, the request latency, or the path a request takes in your microservices architecture. You can use this information to detect app failures, find bottlenecks, or investigate malicious activity. |
| Response caching | If the same client request is sent multiple times in a certain timeframe, you can configure the API Gateway to cache the response from your microservices so that the API Gateway can serve these requests directly without forwarding the request to the microservice. This setup significantly improves request latency and response time. |