Feature request: support for parseAsync in zod parsing

[cbarlow1993]

Use case

I have several schemas that will attempt to look up values against the database during validation, however these async superRefines are not compatible with this parser as they require parseAsync.

Solution/User Experience

Possibly something along the lines of:

import { asyncParser } from "@aws-lambda-powertools/parser/middleware";
import { APIGatewayProxyEventV2Schema } from "@aws-lambda-powertools/parser/schemas";



const schema =
  APIGatewayProxyEventV2Schema.extend({
    pathParameters: z.obiect({param: z.string()}),
    body: JSONStringified(z.object({ recordId: z.string() }),
  }).superRefine(async (data, ctx) => {
     try {
         const checkRecordExists = await dynamoRead(data.body.recordId)
     } catch (err) {
          ctx.addIssue({
            code: z.ZodIssueCode.custom,
            message:
              "Cannot create data with invalid record type",
          });
     }
}

.use(asyncParser({ schema }))

Alternative solutions

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.

[dreamorosi]

Hi @cbarlow1993, thank you for opening this issue.

Before making a decision on this feature I'd like to finalize our plans for what is discussed in #2431. At the moment we only support Zod as parser library, but with the launch of standard schema we have been considering expanding support to other libraries.

I am unsure whether standard schema supports asynchronous parsing or if it's a Zod-specific feature. It's also still unclear if standard schema will fit our needs, so before making a decision around adding parseAsync from Zod I'd like us to consider these points.

To be completely transparent, this is most likely not something I expect we'll resolve in the next quarter, since we have other items already on our roadmap with more priority.

With that said, I'd encourage anyone stumbling on this issue and who's interested in seeing this added to add a 👍 to the original comment above, so we can continue monitoring demand and potentially adjust our plans.

[jessedobbelaere]

I'm also very interested in this.

I generate a Zod schema from our OpenAPI spec and let the parser validate our request. However, some fields needs extra validation: looking up ID values in the database or another API to make sure they are valid identifiers. At the moment I need to build a second validation layer because the parseAsync feature cannot be used with Parser.

[dreamorosi]

Hi @jessedobbelaere, could you share an example of how you use the parser, and specifically whether you use the Middy.js middleware, class method decorator, or?

[jessedobbelaere]

In essence, I generate Zod definitions from the API spec using astahmer/openapi-zod-client. Then I add a Middy middleware on my Lambda handler(s) with the Parser. The api gateway helper function just extends APIGatewayProxyWithLambdaAuthorizerEventSchema with the query/path/body from the Zod schema of that specific route.

.use(
        parser({
            schema: createAPIGatewaySchema(endpoints.createExport),
        }),
    )

My idea was to extend my generated Zod schema with a custom refine/superRefine, to lookup a uuid field on the request body via an API or db lookup to ensure it's valid. But without async parser support, I need to build an additional Middy middleware or validate the uuids as part of the plain handler implementation. Which spreads the validation logic a bit. Thanks! 🙏