Feature request: Add support for multi-variant AWS AppConfig feature flags

[HaaLeo]

Use case

AWS AppConfig multi-variant feature flags enable users to implement use cases such as user segmentation or traffic splitting. Those use cases are described in more detail here.

Solution/User Experience

Taking the example found here one could introduce an optional context option of type Record<string,string|number|boolean>. Then one could fetch a variant like this:

import { getAppConfig } from '@aws-lambda-powertools/parameters/appconfig';

const result = await getAppConfig('ConfigName', {
    environment: 'dev',
    application: 'MyApp',
    context: {
        email: 'jane_doe@example.org',
        opted_in_to_beta: false
    }
});

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

Looking at the link you shared, and also at the docs, it looks like this feature is only available when interacting with AppConfig via the Lambda extension - if it's not the case, please let me know.

At the moment our Parameters utility is based on the AWS SDK AppConfigDataClient - which doesn't seem to support this type of retrieval.

We have had some initial conversations with the AppConfig team earlier this year, but we haven't made any concrete plans yet - although the option is very much on the table.

To help us with the decision, besides the functional use case that is covered in the issue & links, could you speak a bit more about how you think Powertools could improve or do different than the experience described in the docs (aka using the agent directly?).

I have some assumptions/ideas that I'd like to validate before sharing. Thank you!

[HaaLeo]

Hi @dreamorosi,
thx for the swift reply. I wasn't aware that this is limited to the usage of the agent. I guess the major concern about using the agent directly is the impact on cold starts and the lambda's bundle size. However, we haven't evaluated the impact on that yet.

I think also the developer experience would benefit from adding that feature to powertools directly. I guess we are an example here: Instead of configuring/enabling the agent on the lambda function a developer can just pass an additional option to getAppConfig() call.

[dreamorosi]

I see, thank you.

I wasn't aware either, but the second link you shared has a note that says this:

I also checked the docs of the AWS CLI AppConfigData client and it doesn't seem to have the field.

---

We haven't done any benchmarks, so I can't speak to the performance overhead of adding that layer.

Regarding the developer experience and functionality, it'll still require you to add the layer to the function. Our space of operation is what happens within the Lambda function.

To be very honest with you, I haven't really played with this context feature of extension yet - so I don't know for sure, but my guess is that we can maybe streamline the HTTP request and calling this local API that is exposed by the extension, and perhaps do a Feature Flag utility similar to the one that Powertools for AWS Lambda (Python) has, but that's pretty much it.

Before moving forward I'd like us to test the extension further and see how it works and based on the results, if we think we have a compelling value add, consider doing something in this space.

In the meantime, I'd also encourage others who come across this issue to leave a 👍 to the original post above or leave a comment describing what you'd like to see us do in this area.

[leandrodamascena]

Hey @dreamorosi and @HaaLeo I'd like to add my 2 cents in this discussion!

We have an issue open in Python to add support for the AppConfig extension (the one that brings the agent in) to enable access to some features that are not available through the AppConfig/AppConfigData SDK features. It is also true that the extension adds some cold start penalties - this is kind normal for loading extensions - but it seems that this is more performant than SDK calls (read here), especially in Python functions where boto3 needs to load json and other things.

The experience for customers remains the same when using the parameter/feature flags utility, but under the hood we essentially encapsulate the HTTP call to call the extension and unlock some new features. To be honest I think this should be a valid improvement for this utility.

I guess the major concern about using the agent directly is the impact on cold starts and the lambda's bundle size.

Yeah, thats true that cold start can be higher than without extension, but in theory you don't need to worry with the Lambda's bundle size when deploying because you can use the public layer provided by AppConfig team. But of course this will count a few megabytes towards the total size of the Lambda package - which limit is 250MB.

perhaps do a Feature Flag utility similar to the one that Powertools for AWS Lambda (Python) has

A current limitation of the Python Feature Flags utility is that it only supports Freeform configuration, it does not support FeatureFlags configuration, we need to improve this. If you decide to do this in TS, keep this in mind.

I think if we get more positive feedback here we could consider adding support for the AppConfig extension.

Thanks

[dreamorosi]

Yea, 100% agree and thanks for providing more info about the perf impact.

I looked at the contents of the extension and it's a single binary around ~9MB so all in all it shouldn't be too bad, but to do a more fair comparison I'd like us/someone to run tests that compare something like this:

import { getAppConfig } from '@aws-lambda-powertools/parameters/appconfig';

const config = await getAppConfig({...}); // async outside of handler

export const handler = async () => {}

Versus doing the same thing with the extension + agent combination. This way we could observe the actual cold start impact and decide

[leandrodamascena]

I have this performance test somewhere. Let me find it in my AWS account and I will run it again on Monday with the latest version of the extension. I will post the result here.