Skip to content
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: GraphQL API Event Handler #1166

Open
1 of 2 tasks
FilipPyrek opened this issue Nov 14, 2022 · 7 comments
Open
1 of 2 tasks

Feature request: GraphQL API Event Handler #1166

FilipPyrek opened this issue Nov 14, 2022 · 7 comments
Labels
discussing The issue needs to be discussed, elaborated, or refined feature-request This item refers to a feature request for an existing or new utility need-more-information Requires more information before making any calls

Comments

@FilipPyrek
Copy link

Use case

We discussed it here on Twitter with @dreamorosi and the outcome was that Lambda Powertools for Python already has this feature and this feature request is to re-implement similar feature also in Lambda Powertools for TypeScript.

The problem in our case is that when we use lambda in combination with GraphQL's nested resolvers feature (and mainly AppSync's implementation of nested resolvers) the lambda cold starts begin to stack-up which leads to couple of seconds of aggregated cold starts of all nested resolvers which is very unpleasant.

Solution/User Experience

GraphQL API handler in Lambda Powertools for Python has a resolver library which does the nested resolution inside a single lambda function and instead of creating the abstraction on infrastructure level, as AppSync does, it creates it on source code level. This resolution can be done thanks to informations from $ctx.info.

This way lambda resolvers would be only for top-level Mutation/Query fields and the rest would be done inside lambda function(s).

And it will reduce any cold starts to minimum. (= cold start of single lambda function)

Alternative solutions

1. Query all the data and return it all inside Query/Mutation top level field resolver lambda functions - this way we loose advantage of GraphQL where clients can select what part of data they are interested in, so we can query only the relevant data on backend. 

2. Create simple custom nasty resolver based on `if` statements to distinguish what fields the client is requesting - very nasty source code.

3. Try all possible optimisations to reduce the cold starts. That can be very hard and even in some cases teams can hit a limit where it's not possible to optimize any further..

Acknowledgment

@FilipPyrek FilipPyrek added the triage This item has not been triaged by a maintainer, please wait label Nov 14, 2022
@dreamorosi dreamorosi added need-customer-feedback Requires more customers feedback before making or revisiting a decision feature-request This item refers to a feature request for an existing or new utility discussing The issue needs to be discussed, elaborated, or refined and removed triage This item has not been triaged by a maintainer, please wait labels Nov 14, 2022
@dreamorosi
Copy link
Contributor

Hi @FilipPyrek thank you for opening this feature request!

As I said on Twitter, I think this is an interesting feature that we should consider adding to this library at some point.

At the moment we are focused on implementing Parameters and Idempotency, as well as finishing Lambda Layers and investigating ESM support.

I have added this feature request to the "Ideas" bucket and added the need-customer-feedback label. With this label we would like other readers to consider adding their use case as well as a 👍 to the issue. We'll use these datapoints during our next prioritisation.

@github-actions

This comment was marked as outdated.

@github-actions github-actions bot added the pending-close-response-required This issue will be closed soon unless the discussion moves forward label Feb 28, 2023
@FilipPyrek
Copy link
Author

This issue has not received a response in 2 weeks. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing.

Still relevant

@dreamorosi dreamorosi removed the pending-close-response-required This issue will be closed soon unless the discussion moves forward label Feb 28, 2023
@dreamorosi
Copy link
Contributor

Apologies @FilipPyrek. Yesterday I set up some new automation to handle issues and this was caught in the crossfire by mistake.

Agree that the issue should stay open. I am working on a fix to the automation.

@github-actions

This comment was marked as off-topic.

@github-actions github-actions bot added the pending-close-response-required This issue will be closed soon unless the discussion moves forward label Mar 25, 2023
@FilipPyrek

This comment was marked as outdated.

@dreamorosi dreamorosi added need-more-information Requires more information before making any calls and removed pending-close-response-required This issue will be closed soon unless the discussion moves forward need-customer-feedback Requires more customers feedback before making or revisiting a decision labels Mar 25, 2023
@sthulb sthulb moved this from Backlog to Ideas in Powertools for AWS Lambda (TypeScript) Jun 19, 2023
@travishaby
Copy link

travishaby commented Aug 15, 2023

Very excited at the prospect of this feature! Have seen a few bad implementations of event routing for AppSync handlers out there and at my company, so it would be really great to have an open source one provided by AWS to standardize on so we can stop re-inventing the wheel 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussing The issue needs to be discussed, elaborated, or refined feature-request This item refers to a feature request for an existing or new utility need-more-information Requires more information before making any calls
Projects
Development

No branches or pull requests

3 participants