Do You Really Need an API Gateway?
Do You Really Need an API Gateway?
Why use a piece of software you don't control when you can build things yourself?
Software developers, myself included, think there's nothing they can't build themselves. The question that many of you have when you're planning a new API is whether or not you should use an API gateway. I mean, why would you use a piece of software—and infrastructure—that you don't control when you can build things yourself? You can probably build into the API whatever the gateway offers. Also, adding an extra layer of complexity feels counterintuitive. Right?
This article is brought to you with the help of our supporters: Zuplo and Speakeasy.
Zuplo is the only API Gateway that runs your OpenAPI definition directly. If you care about high-quality developer documentation, API analytics, and zero configuration deployments, give Zuplo a try today.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations. Try Speakeasy now.
Well, don't rush to conclusions. Let's first understand what exactly an API gateway is and what you can do with one. In the famous book "Patterns of Enterprise Application Architecture," Martin Fowler described the gateway pattern as "an object that encapsulates access to an external system or resource." Fowler sees the gateway as a way to abstract how software connects to external dependencies. In Fowler's description, the gateway is something that helps you interact with external APIs. An API gateway follows the same principle but in reverse. It helps external consumers interact with your API.
An API gateway is no more than a server that sits in front of your API to make it easy for consumers to access it. It receives requests from consumers and passes them to your backend API. The first value that a gateway brings is that you don't have to expose your backend API to the public. Instead, you give the gateway access to it. If you change your backend API access or protocol, your consumers won't be affected because they're accessing it through the gateway. In fact, most API gateways can work with more than a single backend service and make them feel like a single API.
Here are some of the common features you can get from an API gateway product:
Request routing: The ability to direct incoming requests to the appropriate backend API.
Protocol translation: Presenting the public API using one protocol while communicating with internal services available in multiple protocols, e.g., translating from AMQP to Webhooks.
Authentication and authorization: Authenticating incoming requests, validating API keys, and ensuring the consumer has permission to access the requested resource.
Request and response transformation: Modifying requests and responses according to the requirements of consumers or backend services, e.g., converting from JSON to XML and vice versa.
Rate limiting and throttling: Preventing abuse and ensuring fair usage by limiting the rate of requests and throttling abusers.
Logging and monitoring: Tracking usage, identifying potential issues, and generating analytics.
Caching: Storing frequently requested responses for later use.
Load balancing: Distributing incoming requests across multiple instances of a backend API to ensure availability.
Most API gateway products in the market don't include all these features. And, in most situations, you wouldn't need them all, either. API gateways offered by cloud providers, such as AWS, Azure, and Google Cloud, abstract the connection between consumers and internal cloud services. In other words, to take full advantage of each one of these gateways, you should have your API running on the corresponding cloud provider. Other commercial gateways connect to your API, wherever it's hosted. Companies like Zuplo1, Tyk, and Gravitee offer hosted gateway products that can work with your API, independently of its location. With open-source software such as Kong, KrakenD, and Apache APISIX you can have the API gateway installed and managed by yourself.
So, now that you know what an API gateway is and does, do you really need one? If it takes you more effort to implement the features you require than using an API gateway, then you need one. If you work with one of the cloud providers I mentioned above, then things get easier if you use their gateway. If you work with multiple backend APIs, each having its own protocol and media format, then you need a gateway to offer translation and transformation. If your business depends on the availability of your API, then you need a gateway to handle load balancing. If you serve your API to multiple geographies, then you need a gateway with caching and edge content delivery capabilities. If you want to make sure that all your consumers are behaving fairly, then you need a gateway to provide rate limiting and throttling.
If not, then you probably don't need a gateway, and you're fine with your single API server. However, you will, most likely, end up implementing some of the features yourself. One of the first things that any API needs is authentication, and you'll have to build it yourself if you don't want to rely on what a gateway product can provide. If you use Node.js, you could use the node-oauth2-server, which works well with Express. Or, you could use the django-oauth-toolkit, if you use Python. Then, you'd have to maintain your own credential storage and make sure everything is properly secured and backed up at all times.
Another feature that you could implement yourself is throttling. You could, for instance, write a system that would apply exponential backoff to make the rate of requests to your API slow down. You'd have to temporarily store the requests that you'd hold until the backend could accept them. To do that you could use a Redis queue where each request would be held for a specific period. Of course, you'd have to maintain the Redis service yourself, otherwise, the whole throttling system would fail.
I could go on and give you more examples of things that you'd need to build yourself to get all the features an API gateway can offer. But I think by now you get my point. Whether or not you need an API gateway really depends on your appetite for getting your hands dirty. And, by appetite, I mean your technical knowledge and also your budget. You see, spending time building these things yourself will take time and effort. Instead, you could rely on a ready-to-use, fully managed gateway, and spend your time growing your API product.
Disclaimer: Zuplo, one of the API gateway products mentioned in this article, is one of the sponsors of the API Changelog newsletter.