API Gateway is a service offered by AWS and was established originally as a code fork of thier CloudFront service and has evolved separately ever since.
Although an interesting fact there has been little evidence to show any sort of relationship between the 2 services since API Gateway was released.
API Gateway today abstracts the concept of CloudFront's distributions and extends on its behaviors and integrations. We can see residual effects of the CloudFront code fork in certain limitiations such as;
- Like earlier versions of CloudFront, API Gateway today suffers from the maximum timeout period of 30 seconds for integrations to respond whereas CloudFront today offers advanced configuration of its behaviors and integrations lacking in API Gateway.
- Caching of any Resource that is not a
GETMethod is stored statically with the cache key being only the Resource and Method combination, regardless if the input body changes the response will remain the same when served from cache. This is not surprising as earlier versions of CloudFront had caching enabled only for GET requests and limited ability to white-list request features such as headers, query parameters, and request body.
- API Gateway endpoints are located in multiple regions, with latency-based routing. Just like CloudFront.
- It is impossible to set the same custom domain on multiple API Gateway configurations because it is still basically CloudFront under the hood.
CloudFront has continued to evolve and receive feature enhancements and patches while API Gateway seems to remain mostly unchanged with its feature offerings and limitations imposed by it's fork of an earlier version of CloudFront.
It is therefore obvious that the parallels we draw between CloudFront and API Gateway must end at that they both receive internet facing traffic and offer business rule based routing of that traffic to other AWS service offerings as integrations. I point this out simply because the CloudFront that once was is not the same CloudFront today and API Gateway by all appearances has taken an entirely different release path.
API Gateway re-design?
Will there be an API Gateway re-design?
I have heard mumblings at AWS events and meetups that there is ongoing developments with the above limitations and more being worked on, but I won't be holding my breath on this mainly due to it's stability, adoption, and release track record.
What would I hope to see in a API Gateway re-design? Easy;
- Regional API Gateway service
- Support being put behind a VPC
- A more intuitive way to use custom domains
- Certificate Manager integration for HTTPS
- Perhaps TLS 1.3 / HTTP2 support
- Exposed behaviour configurations similar to modern CloudFront
- Full availability of Load Balancer options from EC2
- Be available in CloudFront as an origin for better caching
- remove all cache from API Gateway or make clear distinctions that it's a static request cache only.
- As an origin setting, you would want API Gateway to be region based and have CloudFront route requesters from certain regions onto appropriately mapped API Gateway ID's in each region
I'm fairly certain I could continue this list focusing on areas of validation, integrations, stages, quota's, and authentication particularly - but I wanted to keep this a short post.
Thank you for reading and don't forget to share this if you found it interesting.