This week I’ve been focused on improving our API Gateway support (check this issue for more info). While we’d love to support everything AWS has to offer, we couldn’t help but notice some features are more useful than others for most users.
So what do you think the most important/critical feature is for your project? And generally, how do you think we can improve API Gateway even further for you?
Looks like you have the request/response templates already planned. I just wanted to add that since Lambdas reject form encoded data right now, to me that addition seems fairly critical. Or is there a workaround?
It looks like it is implemented but not documented in the current 1.0-beta version. If I have time I can start playing around with it in the next few days and come up with some examples for the documentation.
I think that being able to fully customize integration request/response is a key feature. As fully customize I meant:
Define a “serverless template” that could be reused among several API Gateway resource functions, pretty much like the v5 did.
Allow us to configure Mock integration requests and AWS Service Proxy integration request which makes easyier to connect API Gateway to AWS services directly.
Allow mapping response status, headers and body for at least JSON content and TEXT content (commonly used in rest errors response),
Also important would be:
Enable cloudwatch logs and metrics to deployed stages.
Support the setup process of custom domains with AWS issued SSL.
Allow a custom CORS lambda function to be declared in Serverless.yaml similar to authorizers (ie, an easy, no verbose YAML block that describe a general OPTIONS lambda function with a mapping to the CORS response headers) which could be later reused in multiple resource http events.
Those are some great points! Thanks for taking the time to write them out, definitely gave me some good ideas. Some of it will be in V1 (e.g. request/response template), some in a later release but can be done at the moment through custom resources.
Another helpful feature, although not related with API GW, would be having script hooks for pre/post deployment allowing us to perform extra tasks outside of the Serverless scope but required for the final application to run (ie running migrations, provisioning external resources, etc). Something like running a named make file.
HTTP Service Proxy would be a feature we would love to have supported. We’re actually holding off on upgrading from v0.5.6 to v1.x because Service Proxies don’t appear to be implemented yet. Also, the CORS and IAM solutions appear to still be in flux, and it seems best to wait until they settle and are documented. Even if I’ve misinterpreted the finality of these two features, it still reflects how confusing it is for us right now to understand where things are in the documentation and our hesitation to upgrade.