Feature request: Add AppSync Resolver Event Schema to Parser

[svozza]

Use case

I would like to use the Powertools parser library to parse the AppSync lambda resolver event. (The fields are described here: https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html) It would be nice to be able to use an off the shelf Zod schema from Powertools rather than hand-rolling the schema myself as I am currently doing. Happy to work on this PR myself.

Solution/User Experience

It would work like any of the other built-in schemas that Powertools currently supports: https://docs.powertools.aws.dev/lambda/typescript/latest/utilities/parser/#built-in-schemas.

Alternative solutions

User can write the Zod schema themselves.

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[dreamorosi]

Hi @svozza, thank you for opening this issue.

Before deciding whether to move forward or not, I'd like to ask for @leandrodamascena's opinion on this since I noticed that the model/schema is also missing from the Python version of Powertools for AWS.

Leo, do you know why we didn't add this in Parser, and if it makes sense to add it?

[svozza]

I thought the AppSync resolver was supported in Python: https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_classes/#appsync-resolver. Or is that different?

[dreamorosi]

That's different.

Powertools for AWS Lambda (Python) has two utilities that share some overlap: Data Classes and Parser. The main goal of the former is to provide type hinting and code completion for common event types at authoring time, as well as some basic runtime benefits around decoding/deserializing nested fields.

In this version of Powertools for AWS we opted to skip Data Classes entirely and focus on Parser. In the TypeScript ecosystem there're already established packages for AWS events like @types/aws-lambda which are not planning to replicate at this time.

If you want to simply type the event in your function, you can use the type from that library (which comes already installed with Powertools for AWS) roughly like this:

import type { AppSyncResolverHandler } from 'aws-lambda';

export const handler: AppSyncResolverHandler = async (event, context) => { // event is now of type AppSyncResolverEvent
  // ...
}

Note that this approach, while entirely valid, does not provide any runtime validation nor parsing.

If instead we were to add a Zod schema to the Parser utility, you'd be able to use it to actually parse the event at runtime and ensure that the event has the shape you expected.

[svozza]

Yes, it's the run time parsing I'm in interested in, not the typing.

[leandrodamascena]

Hello folks! I think it makes sense to add the AppSync schema to the parser in TS and Python. We just need to make some considerations in the documentation and implementation.

Unlike other services like ALB, APIGW, Lambda Function URL where you can't mutate the entire payload, in AppSync you can mutate the payload by using Lambda Resolvers + custom code in JS/VTL, in this case the parser model is kind of useless. We need to make very clear that we just support Direct Resolvers and not custom Resolvers.

AppSync also has a difference when working with single resolvers and batch resolvers. Another difference is when resolving parent source fields and when using arguments from arguments fields, this varies a lot in AppSync.

I can help provide feedback in TS if we decide to go ahead with this implementation and after that I can implement it in Python. If we decide to go ahead with this, can you help us to validate it @svozza?

[svozza]

We need to make very clear that we just support Direct Resolvers and not custom Resolvers.

Yes fully agreed.

AppSync also has a difference when working with single resolvers and batch resolvers. Another difference is when resolving parent source fields and when using arguments from arguments fields, this varies a lot in AppSync.

I would envisage two separate schemas where the batch one is just something like:

const AppSyncResolverEvent = z.object(/** ... **/)

// ...

const BatchAppSyncResolverEvent = z.array(AppSyncResolverEvent)

Regarding source, I don't we can do any better there than z.record(z.any())

If we decide to go ahead with this, can you help us to validate it @svozza?

Absolutely! As I said, I'm even happy to implement it.

[dreamorosi]

Thank you both!

@svozza, thank you also for offering to help.

I'd say as a first step let's start with writing up a spec with all the schemas we're gonna add here in this issue, so we can align on implementation even before moving onto the PR.

This way Leandro can also check that it makes sense for Python and then when we agree, we can move to the PR, and Python can add it whenever they see fit.