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.

Sign up for GitHub

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

Jump to bottom

ARN retrieval function consistency for CDK constructs #581

Closed
1 of 11 tasks
sdpoueme opened this issue Nov 10, 2023 · 2 comments
Closed
1 of 11 tasks

ARN retrieval function consistency for CDK constructs #581

sdpoueme opened this issue Nov 10, 2023 · 2 comments
Labels
status/stale The RFC did not get any significant enough progress or tracking and has become stale.

Comments

@sdpoueme
Copy link

sdpoueme commented Nov 10, 2023 •
edited
Loading

Description

Customers use ARN to wire CDK applications and build custom constructs. The ideal way to retrieve ARNs is to leverage a function attached to the CDK object and extract the value. In most cases, there is no consistent way to retrieve ARNs with CDK. Each construct implements its own method and it impacts developer experience.

This consistency will make code easier to read and maintain across organizations. In addition, it will help developers adopting new resources faster. Developers can implicitly guess the function required to retrieve ARNs.

Short description of the proposed feature.

Developers may benefit from a consistent method to retrieve ARNs regardless of the service. e.g: myresource.getARN()

That function will be available to all CDK resources and will use the specific attribute for each to return the ARN value.

Roles

Role User
Proposed by sdpoueme
Author(s) sdpoueme, effearts
API Bar Raiser To be defined
Stakeholders bmckinle

See RFC Process for details

Workflow

  • Tracking issue created (label: status/proposed)
  • API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
  • Kick off meeting
  • RFC pull request submitted (label: status/review)
  • Community reach out (via Slack and/or Twitter)
  • API signed-off (label status/api-approved applied to pull request)
  • Final comments period (label: status/final-comments-period)
  • Approved and merged (label: status/approved)
  • Execution plan submitted (label: status/planning)
  • Plan approved and merged (label: status/implementing)
  • Implementation complete (label: status/done)

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.
@sdpoueme sdpoueme added the status/proposed Newly proposed RFC label Nov 10, 2023
@evgenyka
Copy link

No plans to implement. The implementation drawbacks are too many to warrant the cost. Suggest contributing via PR.

@mrgrain mrgrain added status/stale The RFC did not get any significant enough progress or tracking and has become stale. and removed status/proposed Newly proposed RFC labels Dec 19, 2023
@sdpoueme
Copy link
Author

sdpoueme commented Jan 3, 2024

Thanks for the feedback @evgenyka. We will identify the resources to limit the scope and submit PRs for each of the resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status/stale The RFC did not get any significant enough progress or tracking and has become stale.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mrgrain @evgenyka @sdpoueme