Maintenance: jmespath utility

[rjmackay]

Summary

The recently added idempotency feature adds a dependency on jmespath. While that package has many downloads, it hasn't been updated in 2 years.

This seems like a concern for the powertools tenets:

Keep it lean. Additional dependencies are carefully considered for security and ease of maintenance, and prevent negatively impacting startup time.

The key selection that jmespath is used for could easily be implemented without this dependency (see #1644)

Why is this needed?

jmespath seems unmaintained and not ideal for a production dependency.

Which area does this relate to?

JMESPath

Solution

• Remove jmespath and replace with a much simpler method of selecting the idempotency key
• Replace jmespath with a more well maintained implementation? (https://www.npmjs.com/package/@metrichor/jmespath is slightly more recent and in typescript)
• Fork and own jmespath?

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]

Hi @rjmackay, thank you for opening the issue.

As stated in the tenet, we take the choice of dependencies seriously and have surveyed the different options when first implementing the Idempotency utility.

The jmespath library that we are currently using albeit not having been updated in a while, is maintained by the same people who maintain and govern the JMESPath specification. The module has no dependencies and the specification itself has remained fairly static, which I think are both indicators of why the library hasn't been updated recently.

When auditing the code for the library however, I have found that its implementation doesn't take advantage of modern language features and in general it's hard to reason about. Additionally, and more importantly for Powertools, it also doesn't support some JMESPath features like defining custom functions, a feature that we consider important for the Idempotency utility as well as other future utilities that handle request payloads.

We have indeed evaluated the other library you mentioned but ended up deciding to not use it for two reasons:

• While the library has a more recent release than the original there are already signs that show it might not be a priority for the maintainers.
• We felt more comfortable, as an interim solution, sticking to a library maintained by the same people who own the specification when it comes to major changes in JMESPath

With that said, we are still evaluating our options (including all the ones you mentioned) and are not yet set on using the jmespath library. The Idempotency utility is still in beta and we expect to have a clearer idea that we can share in the coming weeks and definitely before marking it ready for production.

Finally, regarding the value of using JMESPath in the first place versus a simple function, I would suggest we continue the discussion in the other issue you have opened where I have shared our rationale: #1644.