Why You Should Put API Gateway In Front Of Everything

Separation of concerns. Seriously, the title isn't clickbait, and that's the answer. I've never used clickbait tactics in the past and I'll never use them again.

Each of your APIs has several concerns that it needs to address, for example authentication, input validation, rate limiting, accessing a database, etc. Some of them are related to what the code should do for the business, like storing data in a database. Some of them are related to that code being exposed as an API, like authentication. The whole idea of an API Gateway is to group these concerns into those that originate from adding business value and those that originate from exposing that business value as an API, and configuring a component called API Gateway that handles all concerns related to exposing code as an API. This idea isn't completely original, frameworks like Spring (Java), Flask (Python) or Nest.js (JavaScript) do exactly this, but at the code level. An API Gateway component, such as Amazon API Gateway (AWS's API Gateway service), does this at the infrastructure level, decoupling these concerns even more.

Still not convinced? Here's 3000 words about it.

What Is an API Gateway?

An API gateway acts as a centralized entry point for all client API requests, providing a range of features that are essential for any functionality that you want to expose as an API, and which you'd be implementing anyways. These features include security, monitoring, and rate limiting.

The key benefit of using an API gateway is that it enables you to manage all aspects related to APIs in a centralized location, separate from your code. This makes it easier to maintain consistency across multiple APIs, and it lets you separate API-related functionality from product-related functionality, not just at the code level but also at the infrastructure level.

API gateway will act as a mediator between client applications and backend services, or even between different services. This ensures all communication goes through established channels, where security measures can be enforced, and traffic can be monitored. Additionally, an API gateway can provide advanced features such as caching and rate limiting, that will help improve the performance of the underlying services.

What are the benefits of using API Gateways?

One of the most significant advantages is centralized API management that's separate from the implementation of the APIs. By placing an API gateway in front of all of your APIs, you can manage all API aspects from a single component, with a shared configuration, and maintaining consistency across all of your APIs. This means that you can easily monitor and maintain all of your APIs with a lot less effort.

Another key benefit of API gateways is enhanced security. With authentication and access control measures in place, you can ensure that only authorized users can access your APIs. You could implement these security features without an API Gateway, but as the number of APIs grows you'll find it hard to maintain consistency across all of your APIs, and any mistakes can lead to security vulnerabilities.

API gateways also improve scalability and performance. By using an API gateway you can implement rate limiting, allowing you to reject excess traffic before it reaches your service and overwhelms it, in a pattern called load shedding. For multi-tenant applications you can apply rate limiting per tenant, significantly reducing the noisy neighbor problem. Furthermore, API Gateways allow you to cache responses, which can reduce unnecessary load on services.

Finally, API gateways provide valuable analytics insights. By monitoring API usage, you can gain insight into how your APIs are being used and identify areas where improvements can be made, both in performance and scale. These insights can also prove valuable to the business, helping product teams understand what features are used the most.

Overall, one of the central points of an API Gateway is that you can get all these benefits in a central API management platform, that acts as the single ingress point for your backend systems.

API Gateway and API Management

Managing APIs sounds like a non-issue, until your app grows to dozens of services and you need to keep track of how each is exposed. For customer-facing APIs it's a core part of your business: If your customers are accessing an API, that API is part of your product and part of what your customers pay you for.

As I mentioned before, an API Gateway lets you separate the responsibilities of exposing behavior through API from the responsibilities of implementing that behavior. Furthermore, it allows you to concentrate the responsibility of exposing APIs in a single place, for all behaviors that are exposed as APIs, for all services.

Managing APIs is a complex problem, I want that to be clear. An API Gateway doesn't automagically solve this problem, but it does concentrate all those responsibilities in a single place, making the problem more manageable.

Features of Amazon API Gateway

Amazon API Gateway is AWS's managed API Gateway service. It offers the following features:

• Support for RESTful APIs and WebSocket APIs

• Integrations with AWS services

• High Availability and Resiliency

• Easy API Creation and Deployment

• API Operations Monitoring

• Authentication and Authorization

Let's dive into them a bit, to see how Amazon API Gateway works.

Support for RESTful APIs and WebSocket APIs

Amazon API Gateway splits support for RESTful APIs into two paths: HTTP APIs and REST APIs. HTTP APIs are the easy-to-use and cost-effective way. They're optimized for serverless workloads and HTTP backend systems, and can get 70% cheaper and have 60% less latency compared to REST APIs. They're more limited in features though.

REST APIs are designed for workloads that require more features than just being an API proxy, like usage plans, API keys, caching, logging, or tracing. They're a bit more complex to set up since they're more powerful, and they are more expensive than a simple HTTP API. Advice: check out the differences here, then if you need at least one feature not offered by HTTP APIs, go with a REST API. If you don't need any of those cool features, go with an HTTP API.

Finally, we have WebSocket APIs. The general advice here is to use a WebSocket API when you're using WebSockets. Simple, right? FYI, websockets is a two-way communication protocol that keeps a lightweight connection alive between the frontend and the backend, allowing the backend to send information over to the frontend without the frontend having to send a request. The most obvious use cases are notifications: Instead of having the frontend poll every X seconds for new messages, you just open a websocket and when a new message arrives the backend can notify the frontend.

Integrations with AWS services

API Gateway can integrate with HTTP backends, obviously. But it also has native integrations with many AWS services. There are the types of integrations for Amazon API Gateway:

AWS: This type lets you expose AWS service actions. You have configure both the integration request and integration response and set up necessary data mappings from the method request to the integration request, and from the integration response to the method response.

AWS_PROXY: With this you can integrate an API method with the Lambda function invocation action with a flexible, versatile, and streamlined integration setup. This integration relies on direct interactions between the client and the integrated Lambda function. It's also known as Lambda proxy integration. You don't need to set the integration request or the integration response. Instead, API Gateway passes the incoming client requests as the input to the backend Lambda function. The integrated Lambda function takes the input of this format and parses the input from all available sources, including request headers, URL path variables, query string parameters, and applicable body. The function returns the result following this output format. This integration type is the best way to integrate with AWS Lambda.

HTTP: This lets you expose HTTP endpoints in the backend via API Gateway. You'll need to configure both the integration request and integration response, and set up necessary data mappings from the method request to the integration request, and from the integration response to the method response. This integration is also known as HTTP custom integration. Btw, don't confuse this with an HTTP API, they're separate concepts that just happen to share the name.

HTTP_PROXY: This integration type works very similar to HTTP, allowing you to expose HTTP endpoints in a backend, but it's much more streamlined. You don't need to set the integration request or the integration response, API Gateway passes the incoming request from the client to the HTTP endpoint and passes the outgoing response from the HTTP endpoint to the client. Of course, this comes with less flexibility, but most of the times you don't need the flexibility of an HTTP integration.

MOCK: With a MOCK integration you can have API Gateway return a response without sending the request to any backend. This way you can set up and test APIs with mocked responses without the need to set up a mock backend for it. Highly beneficial if you're doing API driven development.

High Availability and Resiliency

API Gateway is designed to scale a lot. In fact, from AWS docs: "API Gateway handles any level of traffic received by an API". Obviously, it's highly available (meaning multiple availability zones), and since it's a managed service you don't need to do any work to achieve this, just create an API and enjoy the benefits. Now, even if you know API Gateway won't be a bottleneck, you still need to protect your backends. There's two ways in which API Gateway can help: Caching and rate limiting.

Caching means that requests and responses are saved in a key-value store, and when the same request comes in again, API Gateway responds with the stored response value instead of sending the request to the backend to re-calculate the value. You can set up a time to live (TTL) for the cache, and when it expires API Gateway will act like it doesn't have the response cached, and if the same request comes in it will send it to the backend.

Rate limiting allows you to enforce a maximum number of requests per minute to send to your backend, which is helpful to avoid overwhelming it. Not accepting traffic beyond what you can handle is a strategy called load shedding, and having API Gateway perform that lessens the burden of your backend, and of your developers since they don't need to implement it manually. Furthermore, if you're using API keys you can apply limits per key. This is especially useful in SaaS applications, where you need to avoid a single customer using up too many resources and affecting performance for other customers (which is called the noisy neighbor problem).

Easy API Creation and Deployment

One of the central points of services like Amazon API Gateway is being easy to use. Now, easy is always relative, and since API management with so many features is a complex problem, the solution will be inherently complex. But with integration types like Lambda proxy integration and HTTP proxy integration, you don't need to worry about that many things.

API Operations Monitoring

API Gateway gives you a dashboard to monitor activity in your APIs. The API Gateway console is integrated with Amazon CloudWatch, so it will also display backend metrics like API calls, latency and error rates. Since API Gateway uses CloudWatch for its own metrics, you can set up CloudWatch alarms for metrics from API Gateway APIs. API Gateway can also log API execution errors to CloudWatch Logs, which can really help with debugging.

Authentication and Authorization

As I mentioned before, one of the best things about using an API Gateway is that you can offload to it responsibilities such as authentication and authorization. These are the authentication and authorization mechanisms you can use in Amazon API Gateway:

You can create resource-based policies to allow or deny access to APIs and API methods, and you can include conditions like source IP address or VPC endpoint.

You can also use AWS IAM roles and policies, both for controlling who can create and manage APIs and who can invoke them. Check out my previous article about IAM to better understand how IAM permissions work.

You can also use Lambda authorizers, which are Lambda functions that control access to REST API methods using bearer token authentication. You can also use headers, paths, query strings, stage variables, or context variables request parameters. This is what you'll use if you're using any identity provider other than Cognito.

Finally, if you're using Amazon Cognito user pools, you can use a direct integration of API Gateway with Cognito to create a Cognito authorizer. It will achieve the same result as creating a Lambda authorizer that calls the Cognito API, but without the work of creating a Lambda authorizer that calls the Cognito API.

Amazon API Gateway in AWS Serverless Architectures

Amazon API Gateway is a critical component in AWS Serverless Architectures. It allows you to expose AWS Lambda functions via a service that can scale as fast as them, and which lets you add api security, authentication, monitoring, and all the other features we already discussed in this article.

Moreover, Amazon API Gateway is itself serverless: As a managed service, you just create an API and manage the configurations from there, without worrying about the underlying services that end up executing those configurations.

With API Gateway's integration with AWS services you can even access DynamoDB or Amazon Kinesis directly, and include authentication features and API keys to control those accesses, but without having to create a Lambda function that just passes the information.

Overall, API Gateway lets you build multiple services for your application and expose them in a controlled, feature-rich and manageable way.

API Gateway and Microservices Architecture

Microservices are defined by their bounded context, which includes data. The key point that makes a service a microservice is that the only way to access the data and the features is through the API the microservice exposes. This way, services only depend on the APIs of other services, not on implementation details about the code or the data (not even the data storage or the data structures). That, plus deploying services independently, is the entire reason why you should use microservices (and if this isn't a problem, you shouldn't use microservices).

Hopefully that highlights well enough how critical API management is in a microservices architecture. If not, let's sing about it. When I say microservices, you say APIs. Microservices! (this is the part where you say APIs).

Any microservices architecture that does anything useful probably has at least a dozen microservices, meaning at least a dozen APIs. That should be hard enough to maintain, but the biggest benefit of an API Gateway in microservices isn't making APIs easier. It's actually in centralizing those features and changes, so you can allow different teams to own each microservice's behavior and API, but not have to worry about coordinating multiple teams in how they implement API features like rate limiting. Each API (and each microservice) can have its own configuration for authentication, authorization, rate limiting, API keys, caching, etc. But it's the configuration that changes, how you implement those configurations across all microservices (and across all teams) remains consistent. That's the biggest value.

If you want to read more about microservices, check out Microservices in AWS: Migrating from a Monolith.

Conclusion

Summing it up: Why You Should Put API Gateway In Front Of Everything? Separation of concerns of responsibilities related to delivering business value and responsibilities related to exposing that business value through an API, so you centralize the latter and DRY (Don't Repeat Yourself). If you're only exposing a few APIs this isn't a big problem, but as systems grow they become increasingly difficult to manage, and you'll dream of having an API Gateway. In a monolith, common programming frameworks will let you separate these responsibilities at the code level. When you're building distributed systems (including but not limited to microservices), you don't want to repeat that configuration across all services, and you want to separate the deployment and scaling of the API from that of the backend that implements the behavior.

Furthermore, if components only depend on APIs, and API Gateway encapsulates the API, then you're free to change the backend that implements the API. This is really common when migrating from a monolith to services using the straggler fig pattern: You isolate the behavior that you want to move to a separate service, put an API Gateway in front of it that points to the monolith, create a service that implements the behavior separate from the monolith, and point the API Gateway to the new service.