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

feat(appmesh): remove from*Name() methods and replace with from*Attributes() #11266

Merged
merged 11 commits into from
Nov 6, 2020

Conversation

dfezzie
Copy link
Contributor

@dfezzie dfezzie commented Nov 3, 2020

Follow Up from #10879

BREAKING CHANGE: all fromResourceName() methods in the AppMesh module have been replaced with fromResourceAttributes()


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@gitpod-io
Copy link

gitpod-io bot commented Nov 3, 2020

*/
public virtualGateway: IVirtualGateway;

constructor(scope: Construct, id: string, props: GatewayRouteAttributes) {
constructor(scope: Construct, id: string, attrs?: GatewayRouteAttributes, gatewayRouteArn?: string) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to props?

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@skinny85 skinny85 left a 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 ifs 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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this removed?

Copy link
Contributor Author

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?

Copy link
Contributor

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 {
      // ...

Copy link
Contributor

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 {

Copy link
Contributor Author

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) {
Copy link
Contributor

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);
Copy link
Contributor

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);
Copy link
Contributor

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 .

Copy link
Contributor Author

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) {
Copy link
Contributor

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);
Copy link
Contributor

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.

@mergify mergify bot dismissed skinny85’s stale review November 3, 2020 20:54

Pull request has been modified.

@dfezzie dfezzie requested a review from skinny85 November 3, 2020 20:56
skinny85
skinny85 previously approved these changes Nov 3, 2020
Copy link
Contributor

@skinny85 skinny85 left a 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 !

@skinny85 skinny85 changed the title refactor(appmesh): remove from*Name() methods and replace with from*Attributes() feat(appmesh): remove from*Name() methods and replace with from*Attributes() Nov 3, 2020
@mergify
Copy link
Contributor

mergify bot commented Nov 3, 2020

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).

@mergify mergify bot dismissed skinny85’s stale review November 5, 2020 00:16

Pull request has been modified.

@dfezzie dfezzie requested a review from skinny85 November 5, 2020 00:17
Copy link
Contributor

@skinny85 skinny85 left a 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.
Copy link
Contributor

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...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm. Fair point..

Copy link
Contributor Author

@dfezzie dfezzie Nov 5, 2020

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

packages/@aws-cdk/aws-appmesh/lib/route.ts Show resolved Hide resolved
@dfezzie
Copy link
Contributor Author

dfezzie commented Nov 5, 2020

Snuck in 2 minor last comments since Mergify dismissed my review for some reason 😜

It was due to the README not being updated with the feat(...) tag. Figure it would be good to get those documented. 😁

skinny85
skinny85 previously approved these changes Nov 5, 2020
@mergify
Copy link
Contributor

mergify bot commented Nov 5, 2020

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).

@mergify mergify bot dismissed skinny85’s stale review November 6, 2020 18:58

Pull request has been modified.

@mergify
Copy link
Contributor

mergify bot commented Nov 6, 2020

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: f3c0646
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Nov 6, 2020

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).

@mergify mergify bot merged commit 13d713e into aws:master Nov 6, 2020
@dfezzie dfezzie deleted the fix/fromResourceAttr branch November 6, 2020 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants