-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(appmesh): remove from*Name() methods and replace with from*Attributes() #11266
Conversation
*/ | ||
public virtualGateway: IVirtualGateway; | ||
|
||
constructor(scope: Construct, id: string, props: GatewayRouteAttributes) { | ||
constructor(scope: Construct, id: string, attrs?: GatewayRouteAttributes, gatewayRouteArn?: string) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change to props?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do that. I changed it since the fromAttributes
methods asked for the parameter to be named attrs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a general rule of thumb when it should be props
vs attrs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what Elad is saying is to add an ImportedGatewayRouteProps
interface that extends GatewayRouteAttributes
and contains the gatewayRouteArn
property, instead of having 4 arguments to this constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Makes sense
* The name of the Virtual Gateway this GatewayRoute is associated with | ||
*/ | ||
readonly virtualGateway?: IVirtualGateway; | ||
readonly virtualGateway: IVirtualGateway; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In EKS, for example we actually only take ARNs here and not strongly-typed objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@skinny85 asked for these to be strongly typed. An ARN would work for this, but this using the constructs is more explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we always use the strongly-typed properties for these, surprised EKS does something different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good first attempt, but I'd like us to use a different structure that doesn't have these weird if
s inside of the imported classes.
this.gatewayRouteArn = props.gatewayRouteArn; | ||
this.gatewayRouteName = cdk.Fn.select(4, cdk.Fn.split('/', cdk.Stack.of(scope).parseArn(props.gatewayRouteArn).resourceName!)); | ||
this.virtualGateway = VirtualGateway.fromVirtualGatewayArn(this, 'virtualGateway', props.gatewayRouteArn); | ||
if (gatewayRouteArn) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really dislike this structure. If there is an if
like this in the code, that suggests to me this class is not needed. I also really hate the "dead code" that throws the validation exception.
How about we do this instead?
public static fromGatewayRouteArn(scope: Construct, id: string, gatewayRouteArn: string): IGatewayRoute {
return new class extends cdk.Resource implements IGatewayRoute {
readonly gatewayRouteArn = gatewayRouteArn;
readonly gatewayRouteName = cdk.Fn.select(4, cdk.Fn.split('/', cdk.Stack.of(scope).parseArn(gatewayRouteArn).resourceName!));
readonly virtualGateway = VirtualGateway.fromVirtualGatewayArn(this, 'virtualGateway', gatewayRouteArn);
}(scope, id);
}
public static fromGatewayRouteAttributes(scope: Construct, id: string, attributes: GatewayRouteAttributes): IGatewayRoute {
return new class extends cdk.Resource implements IGatewayRoute {
readonly gatewayRouteName = attributes.gatewayRouteName;
readonly gatewayRouteArn = cdk.Stack.of(scope).formatArn({
service: 'appmesh',
resource: `mesh/${attributes.virtualGateway.mesh.meshName}/virtualGateway/${attributes.virtualGateway.virtualGatewayName}/gatewayRoute`,
resourceName: this.gatewayRouteName,
});
readonly virtualGateway = attributes.virtualGateway;
}(scope, id);
}
Same comment for all of the other resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. I'll make this change
/** | ||
* Utility method to add a new GatewayRoute to the VirtualGateway | ||
*/ | ||
addGatewayRoute(id: string, route: GatewayRouteBaseProps): GatewayRoute; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My original thought was that this does not make sense to have in the IVirtualGateway
resource. If we were to implement the inline class you suggested, we would need to also implement the addGatewayRoute
method for that class, right?
Thinking about it more, calling addGatewayRoute
would be a valid call for imported virtual gateways, but you could accomplish the same thing by passing the imported gateway to the Gateway Route constructor. What are your thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way we deal with this usually in the CDK is to have an abstract module-private class called <Resource>Base
(so in this case, VirtualGatewayBase
) that implements the resource interface (so IVirtualGateway
in this case), and that class contains the implementation of the methods like addGatewayRoute
. In that case, the inline class should extend from VirtualGatewayBase
instead of cdk.Resource
:
public static fromVirtualGatewayAttributes(scope: Construct, id: string, attrs: VirtualGatewayAttributes): IVirtualGateway {
return new class extends VirtualGatewayBase {
// ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently there's already VirtualGatewayBase
, so your work is easier:
abstract class VirtualGatewayBase extends cdk.Resource implements IVirtualGateway { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at other classes, it looks like they implement a ResourceBase
class in instances like this. I will do the same here
@@ -133,20 +133,36 @@ export = { | |||
}, | |||
}, | |||
|
|||
'Can export and import GatewayRoutes and perform actions'(test: Test) { | |||
'Can import Gateway Routes using ARN and attributes'(test: Test) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you leave this test unchanged, and add a new one for fromGatewayRouteAttributes
please?
test.equal(virtualGateway2.mesh.meshName, 'testMesh'); | ||
test.equal(virtualGateway2.virtualGatewayName, 'test-gateway'); | ||
test.equal(virtualGateway2.mesh.meshName, meshName); | ||
test.equal(virtualGateway2.virtualGatewayName, virtualGatewayName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here - leave the old test as-is, and create a new one for fromVirtualGatewayAttributes
.
|
||
// WHEN | ||
const virtualNode2 = appmesh.VirtualNode.fromVirtualNodeArn( | ||
stack, 'importedVirtualNode2', arn); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here - leave the old test as-is, and create a new one for fromVirtualNodeAttributes
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old test here does not make much sense. It adds a listener to node2
but never does any sort of validation on it. Adding the listener to the imported class does not actually make much sense, as it is modeled outside of the CDK and making a mutating call on it would not be valid.
I can revert it, but it does not provide much value.
@@ -304,15 +304,29 @@ export = { | |||
}, | |||
}, | |||
|
|||
'can import a virtual router'(test: Test) { | |||
'Can import Virtual Routers using ARN and attributes'(test: Test) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here - leave the old test as-is, and create a new one for fromVirtualRouterAttributes
.
const virtualRouter2 = appmesh.VirtualRouter.fromVirtualRouterArn(stack, 'importedVirtualRouter2', arn); | ||
// THEN | ||
test.equal(virtualRouter2.mesh.meshName, meshName); | ||
test.equal(virtualRouter2.virtualRouterName, virtualServiceName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment here - leave the old test as-is, and create a new one for fromVirtualServiceAttributes
.
Pull request has been modified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks @dfezzie !
Thank you for contributing! Your pull request will be updated from master 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Snuck in 2 minor last comments since Mergify dismissed my review for some reason 😜
## Importing Resources | ||
|
||
Each resource comes with two static methods for importing a reference to an existing App Mesh resource. | ||
There are two static methods, `from<Resource>Arn` and `from<Resource>Attributes` where the `<Resource>` is replaced with the resource name. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess Mesh
is an exception to the rule...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm. Fair point..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to include info about importing meshes
It was due to the README not being updated with the |
Thank you for contributing! Your pull request will be updated from master 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.
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Follow Up from #10879
BREAKING CHANGE: all
fromResourceName()
methods in the AppMesh module have been replaced withfromResourceAttributes()
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license