Demystifying API Gateways: What They Are & Why They Matter
Demystifying API Gateways: What They Are & Why They Matter
What is an API Gateway ? Benefits and Downsides of API Gateway
In today’s world, APIs (Application Programming Interface) power software communication. Google, Netflix, Amazon, and Meta handle billions of API invocations daily.
Companies have witnessed several benefits, such as scalability, performance, and agility, from adopting microservices. But the microservices architecture increased the overall complexity of software applications.
With the rise in the number of services, the number of APIs will proportionately grow. The system needs to now solve problems of security, managing service interactions, and performance.
If you're feeling overwhelmed by API complexity in your microservices architecture, fear not! The API Gateway is your superhero, simplifying security, routing, and more, so you can focus on building amazing applications.
In this article, we will dive deep into API Gateway and understand why it’s needed and how it works. We will also take a look at how it solves challenges such as request routing, rate limiting, caching, etc. in microservices.
With that, let’s start our journey by understanding what an API gateway is and why it’s needed.
What is an API gateway?
An API gateway acts as an intermediary between the clients and the backend microservices. It is responsible for handling the client API request, routing it to the right microservice, and sending back the response.
The below diagram depicts an API gateway and its interaction with clients and other components in the architecture.
It decouples the clients from the backend, preventing them from needing to know which specific microservices to communicate with.
It protects the system from bad actors by rate-limiting and throttling requests. Further, it enhances security by authenticating and authorizing the API requests.
Why do we need an API gateway?
Let’s take an example of a ride-sharing app. Imagine that the backend of this ride-sharing app was a monolith. And after extensive analysis, smart engineers decided to adopt microservices.
The monolith is now split into multiple services: User Service, Rider Service, Booking Service and Notification Service. Each of these services exposes multiple APIs for communication. These could be HTTP REST APIs or GRPC-based.
Now, clients such as web browsers or mobile apps will integrate with the APIs for fetching and posting data. The below diagram illustrates the architecture and data flow in the system.
What do you think are the complexities of the above design? Well, there are plenty. Let’s go through each of them and understand them in detail.
Request routing
In the above example, the client needs to know the endpoint or the URL of each microservice. This increases the coupling between the clients and the services.
When services are scaled, clients wouldn’t know the specific service instance that it must call.
Security
Each API request must be authenticated and authorized. With the above design, this functionality needs to reside in each service.
The security functionality needs to be duplicated in every service. If the functionality gets skipped in any service, the system would be vulnerable to attacks.
Performance
At times, certain APIs, such as user profiles, return the same data, as the data doesn’t change. Such APIs can span several services, and the performance can be improved by introducing caching.
With the above design in place, caching needs to be introduced in every other service to make the APIs performant.
Rate limiting
The system needs to protect itself from bad actors. It must detect any load anomalies and automatically block attacks like DDOS (Distributed Denial of Service).
In the above example, every service would need to implement rate limiting and thereby safeguard the system.
Let’s now understand how the API gateway addresses the above challenges.
API Gateway and its benefits
Request routing
The API Gateway has a route configuration that maps the client API requests to the respective microservices’s APIs. It reads this configuration and stores the mapping in its memory.
For eg:- If the client API is GET /api/v1/user/{userId}/rides/{rideId}, then it would map to GET RideService:/api/v1/user/{userId}/rides/{rideId}. The API Gateway knows that it must call the RideService.
The clients such as mobile apss or web browsers only needs to know the API endpoint. In the case this API moves to a different microservice, only the route config needs to be updated. The client doesn’t need to make any change.
Authentication and Authorization
The API gateway authenticates each request by verifying the credentials. The credentials could be username and password or a third-party identity. In cases of invalid credentials, the API Gateway returns the appropriate authorization failure.
API gateways can use identity providers for authentication, depending on the specific gateway and configuration. They also offer various authentication mechanisms, including API keys, OAuth, OpenID Connect, and more.
After authentication, it then validates whether the client has sufficient permissions to invoke the API. For eg:- I can invoke the GET /api/v1/user/{userId}/rides/{rideId} for my userId. However, using a friend's userID would result in successful authentication but failed authorization.
In the absence of an API gateway, every microservice would have to perform authentication & authorization of all API requests. This would lead to duplication of functionality and code.
Rate-limiting
Bad actors exist on the internet, and it’s common to hear attacks such as DDOS. In such attacks, the system is flooded with a large number of requests. And this leads to resource exhaustion and brings down the website.
To avoid this, it is essential to protect the system by rate-limiting the requests sent to the microservices. The rate limiting should be configurable and can be done on a user or IP address level. For eg:- If more than 1000 requests are received within a second, the user must get blocked.
Similarly, the user can be throttled if the number of requests crosses a given threshold. In such cases, the user doesn’t get blocked but can try again at some point.
API Gateway is equipped with rate limiting and throttling. The appropriate rate limits can be configured and dynamically updated.
Centralizing the rate-limiting logic in API Gateway avoids the need to add this logic for the different microservices. Also, developers don’t need to update the rate limit for each microservice.
Caching
API gateways can cache the responses to API requests. This improves performance as the request is not sent to the backend microservice. It saves a network call and also computes, resulting in better resource utilization.
Caching is also configurable, and parameters such as TTL (Time to Live) and cache key can be updated easily.
Protocol conversion
Microservices can support APIs with different protocols, such as HTTP, GRPC or proprietary protocols. However, the client may not be compatible with all the protocols.
API Gateway steps in in such cases and acts as a bridge or adapter. It converts the client’s request from one protocol to another and then forwards it.
Many API gateways offer various mechanisms for protocol conversion. This includes dedicated features, configuration options, or even plugin-based approaches, depending on the specific gateway.
In a nutshell, you can think of API Gateway as a multi-talented infrastructural component. It centralizes cross-cutting functionality and abstracts the backend complexity from the clients.
Now that we have seen the benefits, let’s also look at the downsides.
Disadvantages of the API Gateway
Latency - API gateway is an additional hop that the API travels through. This increases the API latency as the request needs to go through an additional network call.
Single point of failure - In case the API Gateway crashes, the clients won’t be able to access any APIs. This could result in a significant downtime if not mitigated promptly.
Increased complexity - It increases the complexity as it’s an additional layer in the architecture. It makes troubleshooting more challenging.
Let’s now look at some API Gateways that used in production environment by different companies.
Real-world API Gateways
API gateways can be either managed, i.e provided by cloud providers or third parties, or open-source. Here are some examples of API gateways :-
Managed
Amazon API Gateway
Azure API Management
Google Cloud Apigee
Open-source
Spring Cloud Gateway
Zuul
Apigee Edge
While choosing among different API gateways, you need to factor in pricing, ease of use, maintenance costs and flexibility. Managed API gateways are easy to set up and provide all the features out of the box. However, you need to pay your cloud provider for the resource usage.
Conclusion
Microservices architecture offers several advantages, but it comes at the cost of additional complexity. It’s critical to provide secure, reliable, and performant APIs to clients. With multiple services and exploding APIs, it becomes challenging to meet these goals.
API Gateway centralizes the API management and decouples the clients from the backend microservices. It acts as the front-facing service and handles all the client APIs. It hides the internal complexities such as request routing and protocol conversion.
It improves the security of the APIs by authenticating and authorizing the requests. It safeguards the backend systems by providing configurable rate limiting and throttling. Further, developers can improve the API performance by leveraging caching.
So if you are thinking of microservices architecture, you must consider introducing API Gateway. With an API gateway, your developers only need to focus on writing business logic in microservices. The API gateway does all the heavy lifting and hides the complexity from you.
Let me know your thoughts on this article in the comments below. Also, you can write about your experience dealing with API gateways in production.
Thanks for reading the article!
Before you go:
Great article 👍👍