Whenever a new technology gains traction — whether it’s a framework, language, tool, or practice — software developers must distill its true value from the buzz. Many have honed this skill to a fine edge, ready to cut away the meaningless from the meaningful. And with no shortage of new tech, this type of mental weed whacking has become an essential part of the job.

The term API gateway is catching on now. However, for even the most experienced judge of trends, it’s not easy to tell exactly why and how it should be used — especially given the horde of competing products that have flooded the market. Here, I present five tips that will put API gateways into perspective, help you to understand this technology better and ultimately guide you towards success in delivering highly available, secure and observable APIs.

Tip 1: An API Gateway Is a Design Pattern

Of course, an API gateway is a _product _in the sense that vendors have products with the term API Gateway stuffed into their names. However, it’s best to ignore the marketing buzz around the term and instead think of it as a design pattern, or a common solution to a well-known problem. As a design pattern it can be expressed succinctly:

An API gateway consolidates many APIs behind a single endpoint, while providing additional capabilities like SSL termination, load balancing, token-based authorization, retry logic, rate limiting, and monitoring.

An API gateway tries to solve the inherent complexity of calling many backend APIs, as many modern websites are prone to do, by presenting a unified interface that condenses multiple APIs into one. Rather than connecting to each API directly, the frontend code only needs to know the location of the API gateway. That makes frontend code more resilient to change, allowing you to scale API servers (or containers) up or down without affecting clients, change the layout of your internal network, and roll out updates more safely.

Because an API gateway fronts all of your services, it’s often augmented with features that cut across services — like SSL termination, load balancing, retry logic, rate limiting, and monitoring. The interesting thing is that you will find nearly all of these characteristics within a modern, software load balancer. In fact, there’s nothing wrong with using a load balancer as an API gateway. For instance, you could easily deploy the open source HAProxy load balancer between your clients and services, which has all of these capabilities and can relay API requests to the correct service based on the path in the URL.

#api management #networking #service mesh #contributed #sponsored