feat: add AppConfig as a parameter provider

[jeromevdl]

Issue #, if available:

Description of changes:

Add AppConfig in the parameter module.

Checklist

• [ ] Meet tenets criteria
• [ ] Update tests
• [ ] Update docs
• [ ] PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

• [ ] Migration process documented
• [ ] Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jeromevdl]

I need to add the documentation.

[heitorlessa]

I read an env bar for Extension. Is there a RFC to learn more about this behaviour?

For Python, we offer normal integration with AppConfig via the Parameters utility. I couldn’t find a related issue or RFC in the PR hence the ask.

Thanks!

On Sat, 9 Apr 2022 at 12:57, Pankaj Agrawal @.***> wrote:

@.**** commented on this pull request.

In docs/utilities/parameters.md https://github.com/awslabs/aws-lambda-powertools-java/pull/826#discussion_r846617574 :

+!!! info "Info: Extension ARN"

• Make sure you use the ARN for the target region. See the list.

+=== "SAM configuration" +```yaml hl_lines="7 10" +ParametersFunction:

• Type: AWS::Serverless::Function
• Properties:

•  CodeUri: Function
  

•  Handler: org.demo.parameters.ParametersFunction::handleRequest
  

•  Layers:
  

•    - arn:aws:lambda:us-east-1:027255383542:layer:AWS-AppConfig-Extension:68
  

•  Environment:
  

•    Variables:
  

•      POWERTOOLS_APPCONFIG_EXTENSION: 'true'
  

From user experience perspective, is there a way we can build this intelligence within the AppConfig Provider? Like figuring it out from function config etc ?

— Reply to this email directly, view it on GitHub https://github.com/awslabs/aws-lambda-powertools-java/pull/826#pullrequestreview-937118497, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPQBCNZKOQMT74ULYABJLVEFPBRANCNFSM5S5BVZXQ . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

[jeromevdl]

I read an env bar for Extension. Is there a RFC to learn more about this behaviour? For Python, we offer normal integration with AppConfig via the Parameters utility. I couldn’t find a related issue or RFC in the PR hence the ask. Thanks!

Not sure to understand your point @heitorlessa . The aim of this PR is actually to add AppConfig to the Parameters module. There's no RFC, or whatever, just wanted to provide this feature which is available in python. I'm currently looking for another way to detect if the extension is available rather than using this env var. If you know how, let me know...

[heitorlessa]

I read an env bar for Extension. Is there a RFC to learn more about this behaviour? For Python, we offer normal integration with AppConfig via the Parameters utility. I couldn’t find a related issue or RFC in the PR hence the ask. Thanks!

Not sure to understand your point @heitorlessa . The aim of this PR is actually to add AppConfig to the Parameters module. There's no RFC, or whatever, just wanted to provide this feature which is available in python. I'm currently looking for another way to detect if the extension is available rather than using this env var. If you know how, let me know...

Np, I've added a comment on the exact line that suggests Powertools supports AppConfig Lambda Extension - we don't support that in Python today, hence the ask for a RFC.

For your question, AppConfig Lambda Extension runs locally on localhost:2772 - if the socket is open the customer is running AppConfig extension.

Under "How it works"

https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html

[jeromevdl]

@heitorlessa @pankajagrawal16 ==> #827

After writing this RFC, I must admit I'm not so sure it's a good idea to provide this option.

[pankajagrawal16]

@heitorlessa @pankajagrawal16 ==> #827

After writing this RFC, I must admit I'm not so sure it's a good idea to provide this option.

Looking at drawbacks you mentioned in RFC, I would agree as well. So in my eyes, it will add value to support extension bit if we can technically make DX experience like if users adds app config extension to the function and if they were using this module as well, the functionality should just seamlessly switch to get data from cached extension environment. (without need to do any extra config etc via env variable and caching bit within utility)

[heitorlessa]

@heitorlessa @pankajagrawal16 ==> #827

After writing this RFC, I must admit I'm not so sure it's a good idea to provide this option.

this is the best part of writing, it helps us put things in perspective and to perhaps see it from a different angle. I agree too it's best to drop the Lambda Extension part for now.

Future wise, this gives you a better chance to hear customer demand, and work with customers that do use the Extension to confirm whether (1) this would be beneficial, and (2) what a good DX looks like (trade-offs included).

[jeromevdl]

Closing (as per the above comments)