Feature request: GraphQL API Event Handler

[FilipPyrek]

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

• [X] This feature request meets Lambda Powertools Tenets
• [ ] Should this be considered in other Lambda Powertools languages? i.e. Python, Java

[dreamorosi]

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[bot]]

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.

[FilipPyrek]

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]

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[bot]]

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.

[FilipPyrek]

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 👍

[travishaby]

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 😄