Learn More About API Gateways
What is the Purpose of an API Gateway?
An API gateway provides a single ingress and egress point for all client traffic interacting with the backend of your application.
Clients might be the frontend of your application in the form of a web page or app, other internal services from within your organization that need to interact with your application, or third-party client apps and web sites. Like an API proxy, a gateway receives incoming requests and directs them to the relevant part of the system and then forwards the response back to the client. But an API gateway does more than a simple reverse proxy service by offering a unified interface and providing features such as security, load balancing, request and response transformation, monitoring, and tracing.
What does an API gateway do?
A Unified Interface
One of the main benefits of an API gateway is the ability to decouple the complexity of the backend system from the outward-facing API that clients interact with. API gateways are particularly popular with microservice architectures, where an application can consist of tens or even hundreds of loosely coupled services that communicate with each other over a network. By breaking down a system into microservices – smaller components based around business functions – development teams can deliver changes more quickly than with a monolithic design.
However, the greater flexibility and agility of a microservice architecture brings with it greater complexity; each service may be written in a different language or framework and communicates with other components over APIs, RPC or message protocols. This is where an API gateway comes in. Rather than requiring clients from outside the system to interact directly with the various backend services, an API gateway is added to the edge of the system to provide a unified interface for outside clients. The gateway acts as an abstraction layer, providing the outward facing API endpoints for the application as a whole and masking the complexity of the underlying services.
Having this abstraction layer between the backend and clients adds another benefit. One of the advantages of a microservice architecture is that individual teams can release changes quickly and regularly. However, when these changes involve regular updates to the API, it can be difficult for clients to stay up to date. Using an API gateway allows the outward-facing API endpoints to remain more stable, with backend changes impacting the connection from the gateway to the backend but leaving the client side unchanged unless features are being added or removed.
Furthermore, for organizations making the transition from a monolithic architecture to microservices, providing a consistent client-facing interface can make the transition process smoother, as changes to the backend are hidden from view.
Whereas an API proxy simply routes requests and responses, an API gateway offers additional functionality around managing the incoming and outgoing traffic. A gateway can also handle service discovery and load balancing of requests across multiple backend instances. In the case of monetized APIs – where clients pay based on the number and/or frequency of requests – a gateway can manage rate limiting for different clients.
An API gateway can facilitate the process of releasing new functionality to production with canary releases. The gateway routes a specified proportion of incoming requests to a new version of a service, enabling the team responsible to monitor for issues while limiting the impact of any failures. Once the team is confident, traffic is switched over to the new version.
Configuration of the gateway is typically managed through policies applied via a command line interface or admin API, with some gateways also offering a management GUI.
As the entry point to your application, API gateways are ideally positioned to secure incoming requests and protect your system. Implementing authentication and authorization at the gateway can prevent malicious actors from gaining access to the services, while throttling the number of requests and maintaining whitelists and/or blacklists reduces the risk of distributed denial of service attacks. The API gateway can also manage encryption of communications between clients and within the system.
Applying security at the gateway not only reduces the potential attack surface, but also ensures that policies are applied consistently and efficiently. In a microservices architecture, centralized management is more efficient than requiring the same functionality to be implemented for each service, potentially using different languages and frameworks.
When do you need an API gateway?
Although APIs have existed in various forms for decades, the number of APIs has seen huge growth in the last 10 years. This is in part because organizations are increasingly adopting an API-first approach to development. When building a product, rather than tightly coupling the client – such as a website or GUI-based application – to the backend and then building and exposing APIs to allow third parties to interact with the same system, the focus is on providing an outward-facing API that will be consumed by all clients, both internal and external. Not only is this more efficient but it also provides more opportunities for the system to be used.
Take a simple example of an airline with a system for managing flight schedules and availability. The same API can be used by the airline’s own website and mobile application as well as by third-party travel booking services, whether business-to-business or consumer-facing. While an API-first approach avoids duplication of effort when new functionality is released, making the API available through a gateway avoids the clients being impacted unnecessarily by backend changes and allows the airline to monitor and secure usage, manage performance and monetize transactions. For example, the airline may wish to apply different rate limits to requests coming from third-party clients and charge based on the number of transactions.
Although API gateways sit on the boundary between the backend and the client(s), that doesn’t mean they must be externally facing. The purpose of a gateway is to provide an interface for clients to interact with your system, and those clients can be both internal and external.
For example, in the case of an organization with multiple separate internal systems, such as a system for managing product orders and a separate financial system, it may be necessary to allow one system to make requests to the other. An API gateway on the edge of the order management system would allow the financial system to request data about orders. That same gateway may also support a client web application for finance team users to view data and generate reports (which in turn result in requests to the orders system). Of course, it would also be possible to build a single system comprising both these functions and data stores; where the boundary should lie between systems depends on the business needs and context.
Considerations when choosing an API gateway
Before deciding whether an API gateway will do what you need, it’s important to understand what a gateway doesn’t do. In a system built around microservices, each request coming in via the gateway must be routed to the relevant service. The gateway can only route those requests if a network and communication method between backend services already exists. Choosing between synchronous or asynchronous communications and whether to implement this per service or use a service mesh is an important part of the system design, but it is separate from the choice of whether you need an API gateway, and if so, which one.
When choosing an API gateway, consider both your architecture and deployment environment. What do they look like now and how are you expecting them to evolve? You may be building a cloud native system from scratch in order to leverage the benefits of containers and automatic scalability, or you might host the system internally, with plans for a hybrid deployment as the system grows. Some API gateways are designed for a particular environment, whereas others provide the flexibility to evolve with your application.
By design, adding an API gateway to your system adds another hop to all incoming and outgoing traffic. Performance should therefore be a key consideration when choosing a gateway for your system. Not all gateways are created equal, and the additional latency from sending requests via a gateway can have a noticeable impact on the end user. On the other hand, some gateways allow you to track request and response times. That performance data can not only help you optimize your system, but can also provide an indication when something is not working as intended.
Best practices when using an API gateway
As the single ingress and egress point for your system, a gateway needs to secure access to your system. Ensuring users are authenticated and requests authorized before they get through, applying transformations to ensure only the necessary information is included in the responses, and rate limiting and throttling traffic can all be implemented at the gateway.
Being the single entry point to the system shouldn’t mean a gateway is a single point of failure. A robust and reliable design is a good start, but depending on the uptime requirements for your system, you may want to implement a high availability cluster of API gateways. While some gateways require the data store to be replicated for each instance, increasing the overall cost, others support both single and multi-database implementations.
As all traffic flows through the gateway, they are the ideal vantage point for monitoring traffic and observing behavior of your system. Choosing a gateway that collects metrics, supports logging and tracing, and provides dashboards for analyzing trends can give you greater insight to your system and allow you to react quickly to issues as soon as symptoms appear.
API gateways provide a consistent interface for clients to interact with your system and a central point for managing requests and responses. In a microservices architecture, they can be used to implement functionality that would otherwise have to be replicated across each individual service and can help smooth the transition from a monolithic design to loosely coupled services.
Adding an API gateway to your system comes with many advantages, but it also adds another component to configure and maintain, so you need to ensure it’s being used effectively. When choosing a gateway, consider your system’s needs both now and in the future; a high performance, low latency gateway with the option to expand the functionality as your system evolves will ensure it delivers value without adding excess weight to your system.
Want to learn more?
Request a demo to talk to our experts to answer your questions and explore your needs.