The following is from Upstate Interactive’s, Peter B. Smith.

Here’s why and here’s the alternative.

Brian,

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 is nightmare’ish for three reasons:

1. The Documentation is terrible; 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 reason for hiring me is 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, the way that those things are accomplished is an 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. But, 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 infuriation) that I encountered is AWS API Gateway does not support binary data.

A robust feature set is a necessity in a production-grade product. When that robustness is not there, it is fair for a developer to turn his head and select another product. AWS API Gateway lacks support for binary data and does not have a roadmap for completing that functionality.

Now, 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 appears that the people behind AWS API Gateway never discussed the cohesive product with each other, only individually contributing to create a sum of parts.

Finally, 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. AWS API Gateway is the cousin who gets drunk and crashes your dads car when getting more ice for holiday dinner. 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 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.

And the results produced by the team of developers who work on Kong have produced a product worthy of the name. 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.