When building and managing an API, most developers want to keep everything as simple as possible without compromising the performance or functionality of their product. In many cases, an API gateway can be great for doing just that.

But API gateways aren’t a silver bullet when it comes to API management.

Historically, some developers have avoided API gateways because of limitations exhibited by the major players. As well as getting into exactly what those limitations are below, we’ll be looking at how the API gateway landscape has changed in recent years.

All of which prompts the question, even if you’ve previously discounted them, is it worth looking (again) at using an API gateway for your product?

The Problem With (Some) API Gateways

We’ve written previously about the advantages of API gateways, but here’s a quick recap:

• Separates application layer and requesting parties
• Increases simplicity for consumers
• Improves development and increases server load
• Creates a buffer zone against attacks
• Caters to specific customers to improve UX
• Logs metrics to anticipate change

A significant issue here is that many API gateways have been built with enterprise products in mind. We won’t name any names, but phrases like “built for enterprise” and “manage thousands of APIs at scale” appear regularly on many solution provider websites.

In many cases, despite some API gateways being open source products, different functionalities are locked away and available only to enterprise license holders. This can put them out of reach for startups and smaller companies.

And things can be tricky on the technical side, too: a larger enterprise might, for example, implement a gateway using Kubernetes and enlist an engineer to look after containers. This is not only expensive, but adds another layer of complexity for companies to deal with.

As such, we’ve seen increasing demand for a slimmer gateway to save on time and cost, without the need to use a large API management suite just because it includes a gateway.

The Rise of Lightweight API Gateways

In recent years there have been efforts to democratize gateways through offerings like KrakenD, Bloodhound, and Express API Gateway. These products all have their own individual approaches but generally prioritize simplicity and accessibility.

In addition to the rise of microgateways, we’ve seen established services changing, or at least supplementing, their approach to make life easier for smaller organizations looking to add a management layer. Take Kong, for example, which has extended functionality through its Konnect platform.

This simplicity is good news for API developers, and not just because it usually translates to cost-effective pricing models that aren’t built with the enterprise in mind. It also means that rate limiting, authentication, load balancing, versioning abilities and so on can be integrated into API offerings without the steep learning curve sometimes associated with gateways.

There are other alternative layers to help get your APIs in the hands of other developers, too, such as using a product like RapidAPI to build services using APIs with a single SDK, API key, and dashboard. Plus, there are services like IFTTT and Zapier, which regularly talk about integrations and Zaps rather than using terminology typically associated with the API space.

API Gateways, Speed, and Adoption

We spoke to Josh Twist, co-founder of a programmable API gateway called Zuplo that can be used as a proxy over existing HTTP APIs and SDKs to get his thoughts on the matter. According to Twist, “most gateways are built with enormous catalogs in mind, which can be scary and take a long time to set up.” Building Zuplo, he wanted to put agility and developer experience at the forefront.

Zuplo’s test console is a nice example of this; its logs, specific to individual requests, are a far cry from the seemingly infinite logs being spewed out on busy servers. And, when deploying new branches, everything goes live instantly to try. This means that you could, for example, create a private environment for a client or customer on the fly and demonstrate it in real-time.

We recently wrote about the importance of Time To First Call (TTFC), and the combination of simplicity and extensibility offered by a service like Zuplo can be invaluable in that context.

Talking about the impact gateways can have on what Zuplo internally calls Time To Hello World, Josh told us: “The best we could get with a competitor was an hour and forty-five minutes. With Zuplo, we’re aiming for a couple of minutes. And, honestly, I’d like to get it below that.”

Despite being in limited beta and waitlisted at the time of writing, the service already handles 1 billion requests per month. In other words, there’s a healthy demand out there for lightweight API gateways like these.

The (API) Gateway to the Future

Beyond the accepted advantages of API gateways — helping to route requests, insulating clients from how applications are partitioned, etc. —another possibility is reducing the strain on developers. For example, with Zuplo, Twist describes his aim to eliminate what he calls the “infrastructure goop” so that developers can focus on the code that warrants their attention.

It’s an idea that echoes the sentiments of Spotify’s Leemay Nassery, quoted in a previous article, who spoke about how low-code solutions for APIs enable developers to “spend more time solving harder and potentially more interesting problems.” Although gateways aren’t a low-code product per se, the two have some comparable aims.

There have been many API gateways out there for a long time now —Azure, Apigee, AWS, etc. — but they’ve historically targeted larger organizations looking to break down a monolith. Thanks, in part, to the rise of microservices, we’ve seen a new breed of gateways emerge that are far more accessible to cloud-native startups and smaller companies.

With low license fees, low latency, and a small footprint, a microgateway could be the ideal solution for startups looking to address issues like rate limiting, authentication, and request routing with a single product.