feat(appsync): Standalone L2 construct for SourceApiAssociation#27121
feat(appsync): Standalone L2 construct for SourceApiAssociation#27121mergify[bot] merged 21 commits intoaws:mainfrom ndejaco2:main
Conversation
…rt of AppSync Merged APIs
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
|
I went ahead and undid the renaming to not introduce a breaking change. I believe it would benefit from updating the naming, but its not a high priority worth dealing with in this PR. |
|
@rix0rrr any chance you could review? On the service team, we have been cut a few tickets regarding the IAM permissions bugs as well as the construct for Merged APIs so I would like to get this one addressed. |
… not introduce breaking change
MrArnoldPalmer
left a comment
There was a problem hiding this comment.
Just some small stuff for now. Gonna ask for another set of eyes since this is new api surface area that we will need to guarantee backwards compatibility on.
Pull request has been modified.
| // Add permissions to merged api execution role, only if it was not passed in. | ||
| if (!this.definition.sourceApiOptions?.mergedApiExecutionRole) { | ||
| const executionRole = this.mergedApiExecutionRole as IRole; |
There was a problem hiding this comment.
This is not the right way to allow that use case.
If people are passing in a role and they don't want it modified, they can pass role.withoutPolicyUpdates(), or import an existing one with Role.fromRoleName({mutable: false }).
So when implementing a construct, you should feel free to always update the role.
There was a problem hiding this comment.
The existing support works like this where it is not updating the role policy if it was passed in. Would it be a breaking change?
There was a problem hiding this comment.
it might be... since this is pre-existing we can look at changing this separately.
| /** | ||
| * Import Appsync Source Api Association from source API, merged api, and merge type. | ||
| */ | ||
| public static fromSourceApiAssociationAttributes(scope: Construct, id: string, attrs: SourceApiAssociationAttributes): ISourceApiAssociation { |
There was a problem hiding this comment.
I'm not necessarily against adding this function, but its use is very unlikely, right?
There isn't a single API that accepts an ISourceApiAssociation ?
There was a problem hiding this comment.
Yea not currently, but it will be necessary for this: #27170
Pull request has been modified.
Co-authored-by: Mitchell Valine <mitchellvaline@gmail.com>
Pull request has been modified.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Pull request has been modified.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
As part of supporting AppSync Merged APIs, this change introduces a standalone SourceApiAssociation construct for declaring a source api association between a source API and a Merged API.
Why do we need a standalone construct?
I also fixed two issues related to IAM:
Closes #26986
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license