Supporting PROXY Integration for APIG #2174
Description
This is a Feature Proposal
Description
AWS recently released their new Proxy integration for Lambda. It is a vastly simpler way to configure your your APIG->Lambda integration. You can read more details in the docs
Basically what they've implemented is a Lambda integration that makes request and response mappings unnecessary, so your HTTP request gets always mapped in a standard way to Lambda. In your response you provider a Hash like in the following example that will be automatically mapped to your response code, headers and body:
var response = {
statusCode: responseCode,
headers: {
"x-custom-header" : "my custom header value"
},
body: JSON.stringify(responseBody)
};
context.succeed(response);
This is vastly simpler than the existing lambda integration.
That simplicity on the other hand also takes away some of the features and more control that we've implemented or discussed recently in Serverless. A proxy Lambda integration does not allow to set any custom integration response templates, it does not allow to set headers on the integration itself (making CORS how we implemented for example impossible without changing your own code).
While I do see the Lambda_proxy functionality as a win for a much easier implementation of apig->lambda I worry that if we only implement support for one we'll exclude some use cases, e.g. when you want to set up custom headers across various resources and don't want to have to put those headers into your code, but just in configuration so you can share the config easily thorugh serverless variables.
Proposal
My current idea is that instead of choosing either one of the two we support both. We'll add a proxy field to the http event that is true by default and will use the proxy integration from lambda, meaning for most simple use cases you can very easily set response codes or headers for your functions.
If you have a more complex case and want to have the full range of functionality the AWS Lambda integration provides you can set proxy: false and use all the request/response config we've recently implemented or which is currently being built in various PRs
/cc @serverless/vip @serverless/core
Similar or dependent issues: