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

Maintenance: Revisit return types of BaseProvider #1172

Closed
1 of 2 tasks
dreamorosi opened this issue Nov 17, 2022 · 4 comments · Fixed by #1205 or #1223
Closed
1 of 2 tasks

Maintenance: Revisit return types of BaseProvider #1172

dreamorosi opened this issue Nov 17, 2022 · 4 comments · Fixed by #1205 or #1223
Assignees
Labels
completed This item is complete and has been merged/shipped enhancement PRs that introduce minor changes, usually to existing features parameters This item relates to the Parameters Utility

Comments

@dreamorosi
Copy link
Contributor

Summary

BaseProvider was the first base class implemented for the new Parameters utility.

At the time, it was not yet known what each AWS SDK provider would return. For instance DynamoDBProvider might return different types than SSMProvider, so the types in BaseProvider have been intentionally left generic.

This issue serves to track the task that will have to be carried out after all providers have been implemented.

Why is this needed?

To enforce strong typing to the values returned by the utility, whenever possible.

Which area does this relate to?

Parameters

Solution

No response

Acknowledgment

@dreamorosi dreamorosi added on-hold This item is on-hold and will be revisited in the future parameters This item relates to the Parameters Utility enhancement PRs that introduce minor changes, usually to existing features labels Nov 17, 2022
@dreamorosi dreamorosi added this to the Parameters - Beta release milestone Nov 17, 2022
@shdq
Copy link
Contributor

shdq commented Dec 23, 2022

AppConfig API returns Uint8Array, and the python implementation of the AppConfig provider implicitly converts it to a string. I did the same for now, but we have the transformValue function in the BaseProvider, which I think should do that. Correct me if I'm wrong – the result for the end user is to get raw data (binary) or transformed value to the end type, which is json for AppConfig.

EDIT: related PR from python powertools
I think it is just the wrong return type of the function def _get(self, name: str, **sdk_options) -> str: and it actually returns binary. I looked at docs of Configuration is StreamingBody which is response type and app config in python powertools return type is binary.

@dreamorosi
Copy link
Contributor Author

My understanding is that, whenever the user specifies a transform when calling get, we should apply that transform and return the corresponding type. If no transform is specified, we can return as-is. If a transform has to be applied, then yes, it should be handled by the transformValue method from the BaseProvider, this applies to all providers.

I don't have 100% confidence on this, but I think your assessment is correct, and the return type on the Python's function might be wrong. Looking at the docs section for this method, the type annotation seems to be bytes:

# Retrieve a single secret
value: bytes = appconf_provider.get("my_conf")

I think it's worth opening an issue on the Python's repo so that it can be looked at be fixed. If instead we both understood it wrong, then they can clarify what's the expected behavior :)

@dreamorosi
Copy link
Contributor Author

The PR linked above addresses some of the first changes needed to support DynamoDBProvider, SSMProvider, and SecretsProvider.

I have reopened this issue after merging them PR as there might be some additional refactoring needed after the discussion and implementation of AppConfigProvider has settled.

@github-actions github-actions bot added the pending-release This item has been merged and will be released soon label Dec 29, 2022
@dreamorosi dreamorosi removed the pending-release This item has been merged and will be released soon label Dec 29, 2022
@dreamorosi dreamorosi self-assigned this Jan 10, 2023
@dreamorosi dreamorosi added confirmed The scope is clear, ready for implementation and removed on-hold This item is on-hold and will be revisited in the future labels Jan 10, 2023
@dreamorosi dreamorosi moved this from On hold to Working on it in AWS Lambda Powertools for TypeScript Jan 10, 2023
@dreamorosi dreamorosi linked a pull request Jan 10, 2023 that will close this issue
13 tasks
@github-project-automation github-project-automation bot moved this from Working on it to Coming soon in AWS Lambda Powertools for TypeScript Jan 10, 2023
@github-actions
Copy link
Contributor

⚠️ 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.

@github-actions github-actions bot added the pending-release This item has been merged and will be released soon label Jan 10, 2023
@dreamorosi dreamorosi added completed This item is complete and has been merged/shipped and removed pending-release This item has been merged and will be released soon confirmed The scope is clear, ready for implementation labels Jan 13, 2023
@dreamorosi dreamorosi moved this from Coming soon to Shipped in AWS Lambda Powertools for TypeScript Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
completed This item is complete and has been merged/shipped enhancement PRs that introduce minor changes, usually to existing features parameters This item relates to the Parameters Utility
Projects
None yet
2 participants