When APIs Go Wrong: The Overambitious API Gateway
The API gateway is not an ESB, and trying to use it as one will probably result in another episode of when APIs go wrong.
Join the DZone community and get the full member experience.Join For Free
After some years working in the API space and event-driven architecture, I have found organizations struggling with APIs, API gateways, and with API management in general. In the previous blog of this series, Forgetting the “I” stands for “Interface” and not “Implementation”, I shared the pitfalls of merging the concept of API implementation with the contract, limiting the flexibility offered by the API decoupling. This time we will be covering the horrible overambitious gateway.
Some time ago, we were trying to explain the benefits of the “separation of concerns” within API management and application connectivity and integration. We were trying to find a simple way to explain why the proposed technology was structured in certain ways. Suddenly, we found that we were not the only ones looking at the emergence of certain antipatterns. What we were looking for was nicely explained in the ThoughWorks Technology Radar: Overambitious API gateways.
It was first detected in 2015 and went over as a HOLD (Proceed with precaution) up to late 2018. If you have been in the enterprise development space for long enough you can easily identify what it talks about. For anyone doing integration in the last 10 years, you certainly had to interact with an ESB. If you recall it, the first implementations of API gateways and the first providers came from traditional ESB implementations. The problem, and hence the antipattern raised when people continue to treat the API gateway as if it was just another ESB.
With the shift of application deployments to microservices and the cloud, the use of API gateways just become more specialized as they now need to run in a distributed environment and be really performant. This means that they need to be lightweight. Something that was going against the previous approach of the heavily centralized ESB.
However, in this transition moment, the API management culture was just starting and several organizations treated the gateways as ESB pushing more and more complex business logging into the transformation phase of the gateway. This resulted in “complex programming in environments not well suited to the purpose” as you can read in the Technology Radar. Adding latency to the calls and requiring specialized developers to craft the necessary Enterprise Integration Patterns and transformations.
In a more healthy vision, the API gateway should only deal with essential generic concerns, preferably not even peeking in the payload. Some examples include business-based rate-limiting, basic routing, authentication, and security. Anything more complex that requires domain knowledge should be processed in a second phase where you can reuse the tooling designed for these types of tasks. In this way, you can offload the responsibilities to the correct elements of your architecture.
The API gateway is not an ESB, and trying to use it as one will probably result in another episode of when APIs go wrong. Where you will need specialized skills to implement policies and you will lose the benefits of easily distributing your micro-gateways along with your microservices.
Opinions expressed by DZone contributors are their own.