Feature request: transform: 'json' should return an array for StringList stored in SSM

[maximang]

Use case

StringList stored in SSM are mainly used to store arrays. The first thing people usually do, is splitting the StringList into an array right after having retrieved it from the Parameter Store.

Solution/User Experience

In the Parameters Powertool, when the transform: 'json' option is used, automatically transform the StringList into an array.

We can also provide an extra transform option value (transform: 'array' for example), just made to handle this case. But it would be disappointing for people getting multiple parameters at once, using getMultiple/getParameters.

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.

[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 @maximang, thank you for opening this issue.

Would you be so kind to please provide an example of the data structure you have stored in SSM, its configuration, and the data structure you'd expect after retrieving it and parsing it?

This would help us recreate an example and understand better the request.

Thank you!

[maximang]

Hi @dreamorosi,

Here is an example of the data structure :

/my-application/tenant-id/settings/countries (StringList)

FR,DE

/my-application/tenant-id/settings/credentials (SecureString)

{
  "clientId": "xxx",
  "clientSecret": "xxx"
}

/my-application/tenant-id/settings/features (String)

{
  "showCancelButton": true
}

Powertools usage

import { getParameters } from '@aws-lambda-powertools/parameters/ssm'

const path = '/my-application/tenant-id/settings'
const parameters = await getParameters(path, {
  decrypt: true,
  maxAge: 300,
  recursive: true,
  transform: 'json'
})
console.log(parameters)

Expected output

{
  "countries": ["FR", "DE"],
  "credentials": {
    "clientId": "xxx",
    "clientSecret": "xxx"
  },
  "features": {
    "showCancelButton": true
  }
}

[dreamorosi]

Thank you for providing the examples.

I can see how having the StringList parsed into an array could be useful, however I'm not yet sure on what's the best way to tackle this.

My current thought process is that using the json transform for this would be technically incorrect since even in SSM the value is stored as a comma-separated string, which when ran through JSON.parse() remains a string. With this in mind I don't think we should modify the transform function to handle StringList values in any special way.

If we were to make a change in the current handling, the most appropriate place I can think (for now) is in the logic that retrieves the parameter (here).

We could add a special handling in the logic that splits the StringList value into an array of strings, but I'm equally unsure about this change since it would modify the behavior for customers who want to get the value as-is.

To be very honest, none of these changes seem correct to me, but none of them is completely off the table. Maybe a better way would be to allow customers to pass their own transform function, so that you'd be able to implement your own behavior if you decide to do so.

Before making a decision I'd like to:

• hear from the @aws-powertools/lambda-python-core team to hear how they deal with this case
• hear from other customers how they're dealing with this case

[dreamorosi]

Circling back here after a few months to update on the issue.

From my side, I still agree with the statements in my previous comment - in addition to these, making this change now would also mean making a breaking change since customers might be relying on the current behavior and applying their own transform.

I've checked with other versions of Powertools for AWS how they handle this case, and in Python they have the same logic as us - meaning no special treatment for this kind of value.

I'll leave the issue open for a few more months, to see if it gains tractions - I still would like to give time to people to find this and share their use cases before deciding if this should be added or not.