-
Notifications
You must be signed in to change notification settings - Fork 365
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 request: Async support for ApiGatewayResolver #3934
Comments
Thanks for opening your first issue here! We'll come back to you as soon as we can. |
Hey @pkucmus! Wowww, we're diving into some pretty cool Feature Request here: making our EventHandler and all its resolvers work async and add more flexibility to enhance I/O operations. But it comes with some significant changes ahead. To be completely transparent, I'm unable to quantify the extent of work needed to implement this capability right now. Perhaps we should consider drafting an RFC to outline the process in detail. It might even be worth exploring the creation of entirely new resolvers that operate entirely async. It's encouraging to see "thumbs up" from many people regarding this matter, and I believe we should seriously consider it. To ensure we stay on track, I'll add some labels such as "revisit in 3 months" and "need help" to keep this issue on our radar and facilitate brainstorming for a solution. Thank you and please let us know if you have in mind any kind of implementation or solution for this. |
Thank you @leandrodamascena, what a nice approach for a random idea like that. I would be happy to put in some work into this. Maybe this would not be as replacement for the existing resolvers but something additional? If you would like I could draft something but I would need to understand how it's currently working, i.e. the use of the global state is confusing me a lot - I'm sure there's a reason for it but I don't know why we're storing and accessing the event in a powertools-lambda-python/aws_lambda_powertools/event_handler/api_gateway.py Lines 1814 to 1815 in c3e36de
|
We're truly appreciate the possibility of you working on a draft for how we can incorporate support for Async in our resolvers and make it work.
This code is a little older, probably from when we created the Event Handler utility, but it is still in use. Payloads are different when working with Event Handler, and we store the event and context in the ALB - https://github.com/aws-powertools/powertools-lambda-python/blob/develop/tests/events/albEvent.json All of our resolvers inherit from Does this explanation cover what you need, or would you like more information? Feel free to ask if you need further clarification!
Of course, there is! Please feel free to share any questions or blocks you have, and we can collaborate to find the best way to move forward. Thank you for taking the time to collaborate on this matter! 🌟 |
Use case
I would love to be able to use asynchronous Python with Powertools. I understand there is not as much need for it in a Lambda runtime as a Lambda (process) will handle only one event but I would still be able to use async-only libraries like encode/databases (with the likes of Neon) or simply reduce my execution time by utilizing
asyncio.gather
when doing concurrent waits for I/O operations.Solution/User Experience
I imagine being able to use it similarly to what the GraphQL resolver does:
Alternative solutions
No response
Acknowledgment
The text was updated successfully, but these errors were encountered: