When I published my recent story about where API gateways might be going, I received pushback the most about my inclusion of code execution as a core platform capability. Which I would agree with in our grandfathers or even father’s API gateway realm, but in a gitops, serverless, edge, and programmable API gateway realty, I see things differently. I see a world where the API gateway is part of the fabric of the web. Our father’s API gateway ended up baked into the cloud, but the next generation of API gateways will just a DNS record away, while enjoying a federated and programmable life serving up goodness (not always).
A gitops driven API gateway brings the API engineer and gateway closer, but a serverless API gateway opens up the possibilities of different relationships between the code behind an API and the gateway. An API deployed at the edge using an API-first gateway, elevates the programmability of the API gateway to new levels. I want every instance of an API gateway in any cloud, region, and provider to have a consistent API for automating the deploying, configuration, and runtime for the gateway. Hell, I want each gateway to be able to program itself and adjust it’s own behavior to match what ever is needed. I just don’t think the code being executed when an API request is made or event triggered is as straightforward as it used to be.
I want my modern API gateway to be just the basics when it is first fired up. I want the minimum viable security and traffic management capabilities available. Then depending on which policies I apply to my gateway, additional capabilities are enabled. I want the security, traffic management, mediation, transformation, virtualization, change management, and code execution to be enabled or disabled based upon a common set of policies I need to deploy and operate any API in my toolbox. I don’t want just want adhoc code execution at my modern API gateway layer, I want everything NGINX Lua modules and serverless has done for us, but lightweight and performant as hell. I want a smart gateway that will run in many different capacities based upon what I need in the moment, not just when I developed and deployed an API.
I understand why we are all hesitant to inject our business logic baggage into the API gateway. However, I think keeping the code being executed at the API runtime always separate in some backend server something that is evaporating into the API economy. Our APIs are just making other API calls. Our APIs are API-driven. Our APIs inputs and outputs are defined by machine-readable contracts governed by machine-readable policies. When our APIs are just brokering calls to other APIs inside or outside our control, what it means to execute code at the gateway begins to evolve. Pre-request and post-request scripts have gained popularity on the client side, helping us automate how we apply and integrate with APIs, so it make sense for pre-request and post-request scripts to execute at the gateway level, inline or using some other sidecar pattern. After looking through all the ways in which API gateway providers are wiring up our API gateways with our other infrastructure, it is clear that we go back to the drawing board and come up with a modern API gateway code execution strategy.
After looking across the almost 40 API gateway providers, and simmering on the approach of CloudFlare, Zuplo, and the other innovators. I just see the API gateway differently now. I see it differently than I did when I began this research, and I definitely see it differently than when I started API Evangelist in 2010. The notion of where the code behind an API comes from, resides, and is executed has changed. I am sure there are still plenty of bad implementation of code execution at the API gateway to be had, but I am hopeful we can also shift how code is executed as part of the runtime. I don’t we want to be piling up our API gateways with all the business logic that has made code execution such a bad idea historically, but I also think that a much more refined, lightweight, and precise API gateway solution can handle new approaches to code execution. Maybe it is that we were piling on way too many other features, and just a handful of security, traffic management, and lightning fast code execution for different business situations is just what we needed across out sprawling API landscape.
