Add documentation and example of AWSLambdaReceiver

[mwbrooks]

Description

Issue #784 (PR #785) added the new AWSLambdaReceiver. This is an official, built-in receiver for AWS Lambda and should become an alternative to developer using ExpressReceiver with ServerlessExpress.

We should document this receiver by:

• Adding example code in examples/ showcasing the usage
• Adding documentation for the AWSLambdaReceiver
• Updating the AWS Lambda deployment guide to reference AWSLambdaReceiver documentation
  • We are not ready to update the guide to use the receiver (see below)

Once the AWSLambdaReceiver supports OAuth, we can also update our deployment guide to use it.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• example code related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

[aplathan]

I tried to use the AWSLambdaReceiver as my App doesn't need Express, but would benefit from snappier Lambda loading times. I banged my head with "TypeError: AwsLambdaReceiver is not a constructor" for some time as I was upgrading from Bolt 2.7.0 to 3.2.0 at the same time, and thought the error might be related. Finally I realized 3.2.0 doesn't include the compiled code for AWSLambdaReceiver yet.

Would it be possible to have AWSLambdaReceiver included in the next public release even though it's not been documented yet?

Best,
Antti

[mwbrooks]

Hey @aplathan, I'm sorry to hear that you put time into upgrading only to realize that we hadn't released it yet! :(

We've now released Bolt 3.3.0 which includes the AwsLambdaReceiver.

Feel free to give it a shot! I'd love to hear what you think. Once we're confident in it, we'll also look into updating the Lambda Deployment guide to give everyone a snappier experience. ✨

[TheManWhoStaresAtCode]

Hey @mwbrooks, I just gave the AwsLambdaReceiver a shot and can state that I like it a lot. It feels much more natural than starting an express server in a Lambda function. Also I'm a newbie to Bolt I managed to get the setup running after roughly 2 hours. However having a proper documentation would have probably reduced it to 15 minutes. Give me a sign in case I can help you with providing input for the Deployment guide.

[JSSAggie]

@TheManWhoStaresAtCode did you do anything special to set this up?

I tried and I keep getting [WARN] Unexpected content-type detected: undefined. I am still digging in but my lambda is pretty much the example one.

I know it is executing the code because that error is in this bolt code for the PR that added the AwsLambdaReceiver.

Edit:
I did some digging in and noticed that I think the issue is that AWS API Gateway lowercases all the header keys and we are looking for exact case.

• https://github.com/slackapi/bolt-js/blob/main/src/receivers/AwsLambdaReceiver.ts#L112
• https://github.com/slackapi/bolt-js/pull/785/files#diff-28e1324e38592888b6be7978f98e3ab7922a41777a4cf142f1c09235b22ed6edR125-R126

Example:
We are looking for a header of Content-Type but my headers come in as "content-type": "application/json", when proxied from API Gateway. Same for "x-slack-signature": "****".

[JSSAggie]

@TheManWhoStaresAtCode did you do anything special to set this up?

I tried and I keep getting [WARN] Unexpected content-type detected: undefined. I am still digging in but my lambda is pretty much the example one.

I know it is executing the code because that error is in this bolt code for the PR that added the AwsLambdaReceiver.

Edit:
I did some digging in and noticed that I think the issue is that AWS API Gateway lowercases all the header keys and we are looking for exact case.

• https://github.com/slackapi/bolt-js/blob/main/src/receivers/AwsLambdaReceiver.ts#L112
• https://github.com/slackapi/bolt-js/pull/785/files#diff-28e1324e38592888b6be7978f98e3ab7922a41777a4cf142f1c09235b22ed6edR125-R126

Example:
We are looking for a header of Content-Type but my headers come in as "content-type": "application/json", when proxied from API Gateway. Same for "x-slack-signature": "****".

I found the documentation that indicates that headers are lower cased. One added detail is that we are using http api vs Rest API on AWS API Gateway.
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

[seratch]

@JSSAggie Thanks for pointing this out. I will create a new issue for it and the bug will be fixed in the next version.

[TheManWhoStaresAtCode]

I'm not using proxy mode for the lambda and my AWSLambdaEvent has uppercase headers:
"headers": { "Accept": "*/*", "Accept-Encoding": "gzip,deflate", ... }
Thus, I'm not getting these warnings mentioned by you @JSSAggie.
Nonetheless according to RFC7230 headers must be case insensitive.

[seratch]

@TheManWhoStaresAtCode Thanks for sharing this. If I remember correctly, I also didn't see the warnings when I deployed my lambda functions with the receiver. Thanks for the info! > proxy mode for the lambda

[seratch]

Thanks to @TheManWhoStaresAtCode 's #940, we can close this issue now!