Feature request: implement `AppConfigProvider`

[dreamorosi]

Summary

The Parameters utility should allow customers to retrieve one parameter stored in a AppConfig.

This work includes the following tasks:

• Write provider + types
• Unit tests (100% coverage)

Why is this needed?

1/ So that customers are able to retrieve parameters from AppConfig, 2/ to reach feature parity with Powertools for Python.

Which area does this relate to?

Parameters

Solution

No response

Acknowledgment

• This request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java

[shdq]

Hello, @dreamorosi. I'm ready to help, but the scope of this PR is bigger than usual, and I don't know where to start. My plan is:

• use implementation in the python repository, as an example. We are porting it to TypeScript, right?
• dive deep into both feat(parameters): SSMProvider support #1187 and feat(parameters): added BaseProvider class #1168 PR's (I glanced at them and I already have a basic understanding)
• I will use AppConfig client from AWS SDK to get actual parameters from service.

Correct me if I'm wrong with my mental model about the Parameters milestone. So the idea is to provide users of powertools ways to get parameters from the range of AWS products, that can store settings, such as AppConfig. But what parameters are that? I still miss some parts of the whole picture. Could you explain in general how it works or share a link to further reading, please?

Speaking of implementation, I need to add my provider class that will extend BaseProvider class and implement two methods _get – for one parameter and _getMultiple for multiple using AppConfig client from SDK.

Thank you for the guidance as always!

[dreamorosi]

Hi @shdq thank you for the bias for action, I'm happy to support you throughout the process.

use implementation in the python repository, as an example. We are porting it to TypeScript, right?

Yes, that's correct. We should support the same behavior and leverage the logic as much as it make sense, while at the same time being idiomatic in JS/TS.

To convey this point, let's look at this function in Python and its corresponding version I have been implementing in SSMProvider.

The Python version uses keywords/named arguments in the function signature, which is a staple in Python. On the other hand, since JS doesn't really have an equivalent and we want to apply strong typing, we are using an object with the configurations.

As a rule of thumb, I would start with a first implementation that ports 1:1 (or rather 1:as-much-as-possible) the Python implementation to JS/TS. Then, after that we can iterate during the review phase or even future PRs before the actual release.

dive deep into both #1187 and #1168 PR's (I glanced at them and I already have a basic understanding)

That's what I would recommend, yes. While you review the PR, please feel free to leave comment and suggestions.

Similar to what you currently see in #1187, I would expect the bulk of the changes to happen in a new AppConfigProvider class, and relatively few changes in the BaseProvider one.

Like you correctly stated, the class you're going to create extends the BaseProvider and implements its abstract methods _get and _getMultiple, which are called by the two public ones (get and getMultiple), which are used by customers/users.

I will use AppConfig client from AWS SDK to get actual parameters from service.

Correct, you can add the SDK as dev dependency for now (npm i -D @aws-sdk/client-appconfig -w packages/parameters) as well as the mock packages ( npm i -D aws-sdk-client-mock@latest aws-sdk-client-mock-jest@latest -w packages/parameters).

Correct me if I'm wrong with my mental model about the Parameters milestone. So the idea is to provide users of powertools ways to get parameters from the range of AWS products, that can store settings, such as AppConfig.

Your mental model is correct.

Generally speaking, we see customers wanting to retrieve secrets like a database connection string, parameters like application ID or other dynamic values that are independent from the code. In the specific case of AppConfig, we see mainly retrieval of feature flags or other more structured configurations that will influence the behavior of the Lambda function, think a multi-tenant application that unlocks some features based on the tenant's membership.

In terms of how we see customers using these libraries, I think the best place to start would be the Powertools for Python's docs for Parameters. If instead you want to read how Lambda use AppConfig, you can read the first half of this blog post. This post is written with Lambda Extensions in mind, however we are going to follow a different implementation strategy, which is a library (Powertools)

Let me know if this clarifies things a bit and also feel free to ask follow up questions. I'm also available to have a call if you think it can help.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues 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.