Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: allow BaseProvider in Parameters to not have a client #2400

Open
1 of 2 tasks
dreamorosi opened this issue Apr 18, 2024 · 0 comments
Open
1 of 2 tasks
Labels
discussing The issue needs to be discussed, elaborated, or refined feature-request This item refers to a feature request for an existing or new utility parameters This item relates to the Parameters Utility

Comments

@dreamorosi
Copy link
Contributor

Use case

When creating a custom Parameters provider I should be able to seamless set my own backend, regardless of whether this might be AWS, a 3rd party, or anything else.

Currently the BaseProvider expects a constructor parameter called proto (as-in prototype, bad name) that you're supposed to pass and that will be used whenever you are not passing an AWS SDK client.

This implementation is too tightly coupled with the notion that BaseProvider expects to be extended by a provider that relies on an AWS SDK client. This is not always the case, and as a customer implementing my own provider I should not have to work around this limitation.

Solution/User Experience

For end customers using the Parameters utility as-is, the experience should stay the same.

For those other customers who implement their own provider, the implementation should be simpler and not require to pass a class prototype to be instantiated as client.

Alternative solutions

No response

Acknowledgment

Future readers

Please react with 👍 and your use case to help us understand customer demand.

@dreamorosi dreamorosi added parameters This item relates to the Parameters Utility feature-request This item refers to a feature request for an existing or new utility discussing The issue needs to be discussed, elaborated, or refined labels Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussing The issue needs to be discussed, elaborated, or refined feature-request This item refers to a feature request for an existing or new utility parameters This item relates to the Parameters Utility
Projects
Development

No branches or pull requests

1 participant