Maintenance: performance tests for parser

[am29d]

Summary

There are many different validation libraries available and we decided to use zod because of the combination of popularity, adoption, open source health and security. This is ideal for customer who already have zod schemas and want to use them in their workloads. For customers who want to start using runtime validation, the questions is which library they should use.

There are different benchmarks on validation libraries performance, but we don't have numbers how they perform in Lambda runtime. It is clear that they will not be faster. But for most customer looking into parser and zod specifically, customers will ask the question how the performance overhead is when using parser.

We should run performance tests for parser validation using zod and compare it to runtime without the parser. The possible variables are: nodejs version, memory, built-in schema, custom schema.

Why is this needed?

We need to understand the performance impact of parser utility and documental it transparently so customer can decide if they can use this utility, without experience negative impact after the implementation.

Which area does this relate to?

Parser

Solution

No response

Acknowledgment

• This 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]

I'll close this issue for now, and in the coming months we'll open a more general issue related to performance testing as described in the roadmap.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.