-
Notifications
You must be signed in to change notification settings - Fork 421
RFC: Static Types for AWS Lambda #144
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
Comments
Having at least |
@heitorlessa what is the best place to give credits for the author of the gist is that in the documentation section where I will describe how you can use the static typing? |
Thanks @Nr18, I'm glad that gist was useful :) |
@alexcasalboni I actually compared it with the But yeah it was a good starting point :-) |
@heitorlessa - I wonder if we can use this to test the side effect of having the tracer turned on during our local testing? Then we don't get any surprises when we deploy a function with powertools turned on. |
@michaelbrewer I do use it in my tests, for example in the from aws_lambda_context import LambdaContext
# Prepare a default context that can be used in tests
Context = LambdaContext()
Context.function_name = "MyFunctionName"
Context.memory_limit_in_mb = 128
Context.invoked_function_arn = "MyFunctionArn"
Context.aws_request_id = "my-request-1" and then in the tests, I would do something like: from tests import Context
from function.index import handler
def test_handler() -> None:
assert handler({"Records": []}, Context) is {"Records": []} In an earlier version, I actually tried to mock more realistic data but then I switched to the |
@Nr18 cool. And then you can enable the powertools tracer without it crashing ? |
I believe that the tracer doesn't work because you don't have a running X-Ray daemon, you could provide the tracer with a mocked provider that would allow the tracer to run I guess but haven't looked into this. |
ah, that is a pity. |
@Nr18 @michaelbrewer good idea! I'd suggest implementing that context-mocking logic in another module, as finding test-related logic in a static typing module might be confusing. Maybe a |
@Nr18 it'll be available in the 1.5.0 release tomorrow :) Thank you again! |
This has now available in 1.5.0 release |
Key information
Summary
When you are developing an AWS Lambda function the handler has 2 arguments an event and a context, the context argument has a fixed structure and methods adding typing would empower the developer because your IDE is now able to give hints on what properties and methods are available.
Motivation
When I developing AWS Lambda function is tent to do this:
This has a downside of having to include the
aws_lambda_context
package for just typing if you need to do that for every single thing your dependency list will grow out of proportion eventually. Besides that the AWS Lambda Powertools exist to make Lambda development easier having hints in your IDE is just that.Proposal
My proposal is to fork the gist @heitorlessa supplied in a discussion (can be found here) into this repository.
I was thinking of creating a
utilities/typing
module where these static type classes would live.For now, the only logical type is the
LambdaContext
(and subtypes) type for the event does not have any value as the content varies too much.Drawbacks
None, if you know one please feel free to leave a comment
Rationale and alternatives
Unresolved questions
None, if you know one please feel free to leave a comment
The text was updated successfully, but these errors were encountered: