-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature flags for lambda_http #497
Conversation
Add feature flags to lambda_http so consumer can decide which service their events come from. This makes compilation much faster when you don't put the same Lambda function behind multiple services. Signed-off-by: David Calavera <[email protected]>
@@ -330,12 +330,6 @@ You can read more about how [cargo lambda start](https://github.com/calavera/car | |||
|
|||
Lambdas can be run and debugged locally using a special [Lambda debug proxy](https://github.com/rimutaka/lambda-debug-proxy) (a non-AWS repo maintained by @rimutaka), which is a Lambda function that forwards incoming requests to one AWS SQS queue and reads responses from another queue. A local proxy running on your development computer reads the queue, calls your Lambda locally and sends back the response. This approach allows debugging of Lambda functions locally while being part of your AWS workflow. The Lambda handler code does not need to be modified between the local and AWS versions. | |||
|
|||
## `lambda_runtime` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed this because it's part of an old readme, and we didn't notice until now. It doesn't make sense anymore in this context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good. Minor comments about wording in the readme.
Use the names present in the API GW documentation to differentiate the APIs. Signed-off-by: David Calavera <[email protected]>
@david-perez thanks for the feedback. I decided to change the feature names to match how the different APIs are described in the API GW documentation: https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html |
Signed-off-by: David Calavera <[email protected]>
README.md
Outdated
@@ -378,6 +372,30 @@ fn main() -> Result<(), Box<Error>> { | |||
} | |||
``` | |||
|
|||
## Feature flags in lambda_http | |||
|
|||
`lambda_http` is a wrapper for HTTP events coming from two different services, Amazon Load Balancer (ALB), and Amazon Api Gateway (APIGW). Amazon Api Gateway can also send events from three different endpoints, Proxy V1, Proxy V2, and WebSockets. `lambda_http` transforms events from all these sources into native `http::Request` objects, so you can incorporate Rust HTTP semantics into your Lambda functions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lambda_http
actually supports three sources: ALB, APIGW, and the new Lambda Function URLs. Lambda Function URLs use the same format as APIGW HTTP API payload format version 2.0. So it works out of box.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, I've updated the readme.
Signed-off-by: David Calavera <[email protected]>
Signed-off-by: David Calavera <[email protected]>
Add feature flags to lambda_http so consumer can decide which service their events come from. This makes compilation much faster when you don't put the same Lambda function behind multiple services.
I've tested these changes in a simple function behind APIGW, and compilation time for a pre-compiled function drops from 18 seconds to 5 seconds.
Signed-off-by: David Calavera [email protected]
Issue #, if available:
Fixes #481
By submitting this pull request