Commercial APIs are not that old of a concept. eBay, Salesforce, and Amazon were pioneering the market when they launched their web APIs only 20 years ago. Over the next two decades, Application Programming Interfaces became the mortar between the building blocks of the web, providing the connection and sharing that the Internet itself was created for. Eventually, at the rise of the API economy, companies started posting and using such a ton of APIs that they needed a separate tool -- an API gateway and later an API management platform -- to support commercial API integration and publishing.
Watch our video to learn about the main API concepts
Let’s explore how and why API gateways were introduced, how they facilitate the API economy today, and how you can implement it.What is an API gateway? Microservices and API gateways
An API gateway is middleware that sits between an API endpoint and backend services, transmitting client requests to an appropriate service of an application. It’s also an architectural pattern, which was initially created to support microservices.Previously, applications were mainly built using the monolith approach -- all software components were interconnected. So, when a client wanted to retrieve data, it would make one API call. A tool called a load balancer (which back in the day was a separate hardware device) would then route all the traffic it got between different instances of an application and return the response to the client. Hard to update and implement new technologies, the monolith started being replaced by a new architectural pattern -- microservices.
Latency. To perform a simple function like logging into the app, the client must make several calls to different microservices. This increased the number of round trips and resulted in longer wait times.
Security. Since each microservice is accessed via a public endpoint, there’s a higher risk of attack. In an ideal world, each service should have authorization but implementing it takes too much time and effort.
Tight coupling. Direct communication means that client apps are tightly coupled to internal microservices and when the latter are updated or retired, this impacts client apps too.
These issues can be solved by introducing an intermediate level between a client and an API that will perform load balancing, provide security measures, and promote loose coupling -- a gateway. Let’s discuss how it does that.
API gateway functions and API management
An API gateway performs purely technical functions. But the same term often has a wider meaning -- an API manager. Let’s draw a distinction here and explain how they’re related.An API manager or an API management platform is business-focused software created to maintain, publish, and manage your APIs throughout their whole life cycle. As we explained in detail in our article about API management, such platforms combine three core functions:
- API gateway, responsible for API deployment, routing, security, and other technical tasks;
- Developer portal, where APIs are documented and become discoverable for users;
- API analytics, the module collecting data from gateways and presenting it on the dashboard.
If you want to learn more about those features, head to the dedicated article. Here, we will talk about technical functions that an API gateway itself performs.
Acting as a facade
The facade architectural pattern is nothing new -- it basically implements a single interface in front of a complex system to improve its usability and provide loose coupling. The facade allows you to maintain and change the location of the backend components with no impact to the client.At the same time, a single point of entry can quickly become a bottleneck and eventually transform into a monolith once again. This is where the backend for frontend (BFF) pattern is used: Applications can have multiple API gateways based on business tasks or client apps (like separate gateways for web and mobile apps).
Routing requests
When you call the receptionist from your hotel room to request a breakfast tray, make a spa reservation, or use the dry cleaning service, they won’t be the one delivering the service to you, but will route your request to the appropriate person. This is done both for your convenience, so you don’t run around the hotel looking for the kitchen or laundry room, and for the convenience of the staff, who won’t have to deal with customer service on top of their main job.An API gateway works the same way, and this approach is called a reverse proxy. Unlike the forward proxy, which hides a client’s origin by retrieving data from the public net on their behalf, a gateway hides the server’s origin and retrieves internal data for the client. The gateway acts as a single endpoint that client apps use, and then redirects all requests to internal (micro)services. This way, only this one endpoint is exposed to the world. At the same time, the gateway can aggregate responses from multiple microservices and send them back as one response, thus reducing the number of calls.
Dealing with cross-cutting concerns
Although the idea behind microservices is full independence, it requires devs to make many of the same decisions and engineering for every microservice over and over again. So, it’s much more efficient to offload some of the functionality to a single tier for consolidation. This includes these various functions as.Authentication and authorization. A gateway is your first line of defense against potential attackers that can perform basic security functions: antivirus scanning, token translation, decryption and encryption, validation, and many more.
Log tracing and aggregation. A gateway keeps detailed audit logs used for debugging, reporting, and analytics.
Rate limiting. A gateway enforces policies against resource overuse (either accidental or deliberate) and allows you to configure API invocation at runtime, so the service is consumed only at the required rate.
Load balancing. To efficiently handle requests, a gateway balances load between nodes of a service to ensure the application’s availability during versioning or other changes in the service.
Translating different protocols
Most external APIs provide responses in the form of REST messages, but your internal services may rely on other formats. For example, legacy systems still only support the SOAP protocol, or you want to benefit from gRPC. The gateway can translate REST calls into compatible protocols without having devs to compromise in their internal architecture. For more clarification, catch our video comparing all API types.
API gateway use cases and implementation options
There are three distinct use cases for adopting an API gateway.In microservices-based systems. An API gateway is a standard for managing microservices environments, for the many reasons that we’ve listed above. For organizations transforming their monolith into microservices, this is a go-to software. Those who already operate on microservices, already use it.
For serverless development. Serverless applications are similar to microservices in the way that they deal with even smaller units called functions. They also require a unified interface and a connection and an entry point for client requests. API gateways are becoming a go-to for serverless computing.
As an entry to API monetization. Employing a full-blown management platform is not an easy task. Nor is it cheap. And even before setting it up, you will have to consider different options, compare them, and test how they fit your needs. This process requires some time and financial commitments, which you do not always have if you simply want to dip your toe in the API economy and see if you want to dive in the pool. For this purpose, an API gateway is easier and faster to set up, and when you see that it works within your business strategy, you can upgrade to the full platform.
Now, the gateway implementation can go two directions: You can choose one on the market, which won’t be an easily reversible decision, or you can build a custom gateway that will come with extra costs.
To help you make the “build vs buy” decision, here are a few prompts for you to think about.
- Consider your existing technologies and skills. Perhaps, there’s a solution created from a collection of other tools that currently provides similar functions. The same team can extend the functionality of the makeshift software if this doesn’t take much time and effort.
- Consult with other people in the company. The choice of gateway will impact many specialists on your team: QA engineers, developers, architects, security experts, etc. They all likely have their own opinions that you should consider in the final decision.
- Calculate the total cost of ownership of a gateway-like solution that you have versus the potential future tool. There are many open source options on the market, so it may be more feasible to pick a popular one if it fits your goals.
API gateway providers
API gateways started as a bespoke middleware. Today, though, there are many providers to help you implement a proxy for any of the aforementioned cases. Let's review and compare them using the following factors:- Open source or proprietary
- Self-hosted or cloud
- Community
- Plugins and integration support
- Technologies used
Kong Gateway -- for modern microservices-based apps
Kong provides a variety of API management functions and its gateway solution exists as two options: an open source product and a licensed one with a few extra features. It’s also versatile in terms of deployment, one of which are premade Docker containers. The open source version runs on premises, but the enterprise one also supports hybrid cloud implementation.Kong is also well-known for its abundant plugins, both official and community-developed, that allow you to transform your gateway into a full cycle API management platform when needed. Although Kong is a solid gateway choice, except for when you’re managing legacy apps -- it can’t transform calls into SOAP or XML formats.
Amazon API Gateway -- for serverless Lambda development
If you’re building a serverless architecture with AWS Lambda, AWS API Gateway is your best option. It’s cloud-only and AWS users can integrate it in a couple of clicks. Their free tier ends at 1 million API calls, so it doesn't hurt to try out, especially since its feature set is comparable to Kong Enterprise.Just keep in mind the vendor lock-in that comes with AWS tools. The tool doesn’t have many third-party plug-ins, so you have to be very confident that you’ll be using it in the long run.
Tyk Gateway -- for enterprise-level development
Tyk might be one of the most approachable vendors as its gateway is open source and free even with enterprise-level features. Easy integration is also in Tyk’s philosophy -- you can write plugins in Python, JavaScript, Go, and more languages, and of course, use plugins created by their growing community.Any protocols are accepted and convertible: REST, SOAP, gRPC, GraphQL, and TCP. If you wonder about any cons, Tyk is under MLP license, one of the less permissive ones.
KrakenD -- for aggregating many microservices
KrakenD claims to be a super-performant API gateway that’s also open source and available for all deployment types: on premises, in cloud, and hybrid. Its unique feature is the declarative way to create endpoints, allowing its use with no programming whatsoever. You can extend its functionality using Go and Lua, but don’t expect much from third-party plugins as its community is quite small.There’s an Enterprise tier with a few extra features like OpenAPI specs generation, but the use of standard features is free and unlimited for all.
Gloo Edge
This tool is based on Envoy Proxy -- the most popular proxy for Kubernetes -- and it tries to follow Envoy’s modern and cloud native traditions. Gloo has an open source and an enterprise editions and both provide the choice of an environment, support serverless functions, and provide routing for gRPC.Other popular providers such as IBM API Connect, Apigee, and Azure API Management also have great options for API gateways but since they’re offering full cycle API management, you can review them in a dedicated article.
What to consider when implementing an API gateway
Although a gateway is a standard way to distribute your APIs, it should be implemented with a few considerations. They’re not drawbacks, but rather vulnerabilities that you must be ready to handle.Risk of becoming a bottleneck. As we previously mentioned, when a gateway aggregates too many microservices, it can bloat into another monolith and become a single point of failure. To avoid this, group microservices based on client type or business logic and create multiple API gateways to manage each group.
Possible performance degrades. An API gateway should help your API grow, which will increase traffic. Your gateway should be ready to handle these spikes and comfortably scale. In this article, Uber documents how they dealt with the scaling challenges for their gateway.
Increased system complexity. An API gateway is yet another component that developers need to deploy, maintain, and update, which results in extra cost and effort. You can overcome these issues with good management and lightweight maintenance processes, but this, of course, requires some skill and experience.
Vendor lock-in. Since a gateway is one of the most critical components of an application, it won’t be easy to migrate to another solution. There’s no way to know if you'll remain satisfied with the provider for years to come, so you can either carefully examine and test all the options, use different providers for different microservices groups, or build a gateway in house. The latter option might not be as difficult and expensive as you expect. For example, you can read about Allegro’s successful building experience.
Regardless of any issues, an API gateway is a crucial component of any microservices and serverless application, and now, you are ready to take the next step in your API management journey.