-
Notifications
You must be signed in to change notification settings - Fork 429
Feature request: APIGatewayRestResolver decorator support for class methods (use case: constructor injection) #1696
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
Thanks for opening your first issue here! We'll come back to you as soon as we can. |
Hey @harwoodjp if you have the bandwidth, I'd welcome a PR for this. The issue is that route method was implement as a closure not an actual decorator that could handle both functions and classes (it's different for classes, specially when preserving identity). It's something I've been wanting to refactor but didn't get the bandwidth yet. Class support decorators is becoming a new ask so we should support this, expand the Middleware Factory utility, and more recently allow the new Middleware support with Classes in mind. Appreciate any help here and can guide any step if you have the bandwidth too. Thanks a lot! |
Adding 'triage' label so we revisit it in upcoming iterations |
I have completed an initial POC pass at API Middleware for ApiRestResolver - the middleware supports any python Callable structure including a class implementing the PR: #2917 |
should this be closed? |
The use is covered, please open a new issue if needed! |
|
Use case
I'd like to decorate class methods with APIGatewayRestResolver's router.
Particularly, I want to use constructor injection in my app. Support dependency injection in lambda parameters is good prerequisite reading.
Here is illustrative code. We have a GET that queries Dynamo with
animal_id
and returns a JSON response:Currently I get the following error:
which indicates
self
argument isn't being passed. So I believe APIGatewayRestResolver router can't decorate class methods.Solution/User Experience
Solution is probably:
self
Alternative solutions
Another solution is to simply use method injection as described by @heitorlessa in Support dependency injection in lambda parameters. This negates the benefits of constructor injection, which is useful when multiple methods share a client, for example.
Acknowledgment
The text was updated successfully, but these errors were encountered: