Skip to content

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

Closed
Nr18 opened this issue Aug 28, 2020 · 12 comments
Closed

RFC: Static Types for AWS Lambda #144

Nr18 opened this issue Aug 28, 2020 · 12 comments
Labels

Comments

@Nr18
Copy link

Nr18 commented Aug 28, 2020

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:

from typing import Any, Dict
from aws_lambda_context import LambdaContext

def handler(event: Dict[str, Any], context: LambdaContext):
    pass

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

  • What other designs have been considered? Why not them? Including the typing every time will not help developers that don't know that they exist
  • What is the impact of not doing this? Developers

Unresolved questions

None, if you know one please feel free to leave a comment

@Nr18 Nr18 added RFC triage Pending triage from maintainers labels Aug 28, 2020
@Nr18 Nr18 mentioned this issue Aug 28, 2020
2 tasks
@michaelbrewer
Copy link
Contributor

Having at least LambdaContext would be useful

@Nr18
Copy link
Author

Nr18 commented Aug 29, 2020

@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?

@alexcasalboni
Copy link

Thanks @Nr18, I'm glad that gist was useful :)

@Nr18
Copy link
Author

Nr18 commented Aug 31, 2020

@alexcasalboni I actually compared it with the aws_lambda_context one and it was exactly the same (because it's not exciting code at all obviously ;-))

But yeah it was a good starting point :-)

@michaelbrewer
Copy link
Contributor

@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.

@Nr18
Copy link
Author

Nr18 commented Aug 31, 2020

@michaelbrewer I do use it in my tests, for example in the tests/__init__.py

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 aws_lambda_context package. Expanding this utility to have value during testing is something that crossed my mind but for the scope of the PR left out for now. If more people think it would be beneficial to extending it with logic to make unit testing easier we should open a new issue and get a discussion going on how that would look like.

@michaelbrewer
Copy link
Contributor

@Nr18 cool. And then you can enable the powertools tracer without it crashing ?

@Nr18
Copy link
Author

Nr18 commented Aug 31, 2020

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.

@michaelbrewer
Copy link
Contributor

ah, that is a pity.

@alexcasalboni
Copy link

@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 tests/mocks module that provides a few useful context objects and a simple way to generate new custom ones? (like a mock factory)

@heitorlessa heitorlessa added pending-release Fix or implementation already in dev waiting to be released and removed triage Pending triage from maintainers labels Sep 3, 2020
@heitorlessa
Copy link
Contributor

@Nr18 it'll be available in the 1.5.0 release tomorrow :)

Thank you again!

@heitorlessa heitorlessa removed the pending-release Fix or implementation already in dev waiting to be released label Sep 7, 2020
@heitorlessa
Copy link
Contributor

This has now available in 1.5.0 release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

4 participants