I came across the term ‘Overambitious API Gateways’ from Thought Works tech radar. The point is about, whether is it good or bad to have business logic in the API gateway? Since the term gateway is not a functional requirement and serves the purpose of reverse proxy; it is quite obvious that including business logic in an API gateway is NOT a good design. But the term overambitious API gateways, seems to be a finger pointing to the API gateway vendors, rather than considering the solution design and development.
I prefer the term ‘Thick API gateways‘ over overambitious API gateways because the implementation is up to the developer regardless of what the tool can offer. In terms of vendor perspective the term overambitious API gateways can be used.
With the advent of microservices architecture API gateways gained another additional boost in the developer tool box compared to other traditional integration technologies.
Microservices favor the the patterns like API composer (aggregation of results from multiple services) Saga (orchestration of services with compensation) at the API gateway. API gateways are used in other business logic like authorization, model transformation and construction and etc. resulting a thick API gateway implementations.
Having said, though thick API gateway is a bad design and brings some awkward feeling at night when you sleep, in few cases it is quite inevitable. If you’re building a solution with different systems and orchestration of the business flow is easy and fast at the API gateway. In some cases it is impossible to change all the backend services, so we should inject custom code between the services and API gateways to achieve this, which would result in technical and budget constraints.
At the same time, as developers when we get a new tool we’re excited about it, and we often fall into the ‘if all you have is a hammer, everything looks like a nail‘ paradigm. It’s better to avoid this.
Let’s see some practical stuff; in fact, what kind of business logic the modern API gateways can include? For example, if we take the gateway service offered in Azure API Management (APIM), it is enriched with high degree of programmable request/response pipeline. In the below APIM policy template I have provided an authorization template based on the role based claims.
The API gateway decides the authorization to the endpoints based on the role based claims. The sections are commented, first it validates the incoming JWT token, then sets the role claim in the context variable and finally handle authorization to the endpoints based on the role claim.
Note: This is a thick API gateway implementation and the pros and cons of this is subject to the problem in hand. This above is a practical elaboration of one thick API implementation.