Thoughts on AWS API Gateway


The experience of using kong has been excellent for the following three reasons:

1. The product works; well, and reliably.
2. The community is active and large.
3. The product is easily extensible.

Contrast this to my experience with the AWS competitor, API Gateway. API Gateway was nightmareish for three reasons:
1. The Documentation was terrible, clearly thoughtlessly written.
2. The product does not have a robust feature set.
3. Extensibility is limited to the machinations of the AWS Dev team.

I started with AWS API Gateway for a client whose main goal of hiring me was to get a production-grade HTTP API live to deliver audio over the web.
Given that the infrastructure of the company was hosted on EC2, S3, Route53, and so on… it made sense to give API Gateway a whirl.

Consider that the objective for most API Gateway users is is something like, “Easily monitor my API usage. Throttle over-active users. Issue and revoke API keys. Meter and log usage data.”

With this consideration, it’s easy to look at the listed functionality of AWS API Gateway and assume that you’ve found the perfect product. Indeed, it does all of those things.

Yet, it is the way in which those things are accomplished which is the issue. It is a developer’s job is to be knowledgable. It is therefore a necessity that technology provide quality documentation to a developer so that he can be knowledgable.

You will find AWS API Gateway documentation to be poor at best, incomplete on average, and infuriating at its worst. The particular case of incompleteness (which in turn led to my infuriation) that I encountered was AWS API Gateway did not support binary data.

A robust feature set is a necessity in a production-grade product provider. When that robustness is not there, it is fair for a developer to turn his head to another product.

This is the same as relationships. When a partner does not provide a sense of completeness, then it is prudent to look elsewhere. AWS API Gateway lacked support for binary data and did not have a roadmap for completing that functionality.

Let me explain to you the feature of cohesiveness, which AWS API Gateway also lacks. To use AWS API Gateway you must also use two template languages, and no less than one but more likely three other AWS products (CloudTrail, Lambda, CloudWatch).

The usage of those templating languages and technologies has the feel of a group of people coming together and sitting in a circle with their backs to each other. Which is to say, it is inferable that the people behind AWS API Gateway never discussed the cohesive product with each other, only individually contributing to create a sum of parts.

The AWS API Gateway is fundamentally limited by the roadmap and capabilities of it’s Dev team. I have spoken in the previous paragraph about the inferable quality of that team, and yet, they would be less dangerous if the product were available to it’s users for improvement.

API Gateway is from the same family as EC2, as S3, as a great number of products whose quality is indisputable. So it is with great chagrin that I report that it does not live up to it’s family name. Not until AWS API Gateway is extensible, in the same way that EC2 is extensible with Amazon Machine Images, enabling developers to put packages of code together to help themselves and each other to be more productive, will it be worth a fresh review.

A great number of AWS API Gateway users, and future users, would benefit from the specific lack in the product which I previously mentioned, binary data support. As well, enough members of that same group would be willing to build that functionality. However, they cannot.

The results of a cohesive team are a product not a sum.

The results produced by the team of developers who work on Kong have produced a product. Among that team, there are two who I believe are deserving of specific mention. They work very well together, and they work with the community. Thijs Schreijer, Thibault Charbonnier. Excellent developers, both. They are members and leaders of a great product team.

I look forward to your reply, and in my response I will spend my time — provided that my client is not spending it for me — on the writing of a letter which addresses the reasons Kong is excellent.