-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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): add Virtual Gateways and Gateway Routes #10879
Conversation
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.
This is quite a doozy, thanks for submitting it @dfezzie!
Not sure I got through the entire PR, but I think I had enough comments to get us started 🙂.
@@ -0,0 +1,41 @@ | |||
import * as cdk from '@aws-cdk/core'; |
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.
We settled on a convention that these sort of module-private utilities would go to a subdirectory of lib
called private
- this way, it's immediately obvious this is not part of the public API of the module.
/** | ||
* What protocol the route uses | ||
*/ | ||
readonly routeType: Protocol.GRPC | Protocol.HTTP | Protocol.HTTP2; |
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 wonder - is the reason the type is not simply Protocol
because there's no TCP
Gateway?
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.
Yeah, I wanted to reuse Protocol
for this, but scope it down to not include TCP. Would you suggest creating a separate enum?
* | ||
* @see https://docs.aws.amazon.com/app-mesh/latest/userguide/gateway-routes.html | ||
*/ | ||
export class GatewayGrpcRoute extends 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.
The fact that these are empty suggests to me the modeling is not quite right here 🙂
|
||
if (props.mesh) { | ||
this.mesh = props.mesh; | ||
} else if (props.meshName) { |
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 wouldn't allow passing meshName
here - instead, require an IMesh
, and the customer can call Mesh.fromMeshName()
here directly. I think supplying both options adds more complication that it's worth.
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.
Will address in separate PR
Co-authored-by: Adam Ruka <adamruka85@gmail.com>
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.
We're getting there - nice work @dfezzie !
/** | ||
* The VirtualGateway the GatewayRoute belongs to | ||
* | ||
* @attribute |
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 @attribute
should not be here...? (These are only for CloudFormation attributes)
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 was following the other resources which have them present in the other IResource
interface.
Looks like lambda is doing this too: https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-lambda/lib/function-base.ts#L19
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.
Right. Lambda is doing it for functionName
, which is an attribute 🙂.
I don't have any problems with gatewayRouteName
and gatewayRouteArn
being @attribute
s in IGatewayRoute
. I just don't think virtualGateway
should be one.
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.
ahh got it. I thought you meant having the attribute
tag in general
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.
@attribute
is still here 🙂
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.
@attribute
is still here 🙂🙂
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 bad!
/** | ||
* Represents the properties needed to define a GRPC Listener for Virtual Gateway | ||
*/ | ||
export class GrpcGatewayListener extends VirtualGatewayListener { |
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 here - make this class module-private?
Co-authored-by: Adam Ruka <adamruka85@gmail.com>
I ended up reverting the |
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.
We're getting closer. I would still like to see a simplified version of the imported classes, and I'm very confused about VirtualGateway
accepting multiple listeners, but then having validation that you can have only one...
* Utility method to add a single listener to this VirtualGateway | ||
*/ | ||
public addListener(listener: VirtualGatewayListener) { | ||
if (this.listeners.length > 0) { |
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.
How does this work for imported VirtualGateway
s?
I think this method should only be defined on VirtualGateway
, not on 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.
I went ahead and removed these methods. We can add them back later!
* | ||
* @default - Single HTTP listener on port 8080 | ||
*/ | ||
readonly listeners?: VirtualGatewayListener[]; |
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.
Considering the condition checked below that a VirtualGateway
can only have a single listener, why is this an array?
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.
We plan to support multiple listeners in the future
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.
So you have to decide between one of two options here.
- Because you only support a single listener right now, change this property to
readonly listener: VirtualGatewayListener
, and we'll add an additional property later that allows you to specify multiple ones. - Leave this as
readonly listeners: VirtualGatewayListener[]
, but remove the validation below that checks there's only one, so that when you lift this limitation on the server side, CDK customers will be able to take advantage of it without the need to upgrade their CDK version.
Right now, this is a "worst of both worlds" kind of situation: you force providing an array, but don't allow specifying more than one because of the validation baked into the class. So the array serves no purpose from what I can see.
I'm leaving the decision to you which of the above options you want to go with 🙂.
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'm leaning more towards option 2.
Option 1 would require customers having to think about two separate fields, listener
and listeners
when creating a gateway/virtual node.
Option 2 has the side affect of requiring server side validation, but you raise a good point on CDK versioning. I would prefer customers have immediate access when we change the server side validation.
Pull request has been modified.
We plan on supporting multiple listeners in the future: aws/aws-app-mesh-roadmap#120 I went ahead and removed the |
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.
We're an inch away 🙂. I want to give a better story around the whole "one listener today" - "many listeners in the future" scenario, because I'm not a huge fan of how this is handled in the current revision. But otherwise, looks awesome!
/** | ||
* The VirtualGateway the GatewayRoute belongs to | ||
* | ||
* @attribute |
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.
@attribute
is still here 🙂🙂
* | ||
* @default - Single HTTP listener on port 8080 | ||
*/ | ||
readonly listeners?: VirtualGatewayListener[]; |
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.
So you have to decide between one of two options here.
- Because you only support a single listener right now, change this property to
readonly listener: VirtualGatewayListener
, and we'll add an additional property later that allows you to specify multiple ones. - Leave this as
readonly listeners: VirtualGatewayListener[]
, but remove the validation below that checks there's only one, so that when you lift this limitation on the server side, CDK customers will be able to take advantage of it without the need to upgrade their CDK version.
Right now, this is a "worst of both worlds" kind of situation: you force providing an array, but don't allow specifying more than one because of the validation baked into the class. So the array serves no purpose from what I can see.
I'm leaving the decision to you which of the above options you want to go with 🙂.
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.
Awesome - thanks @dfezzie !
The PR build is currently broken for unrelated reasons, but we'll get this merged as soon as that's fixed.
Thanks for your patience with this change, and with me 😊
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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…11277) Follows the pattern set in #10879 and transitions the VirtualRouter listener to use protocol specific listeners. BREAKING CHANGE: VirtualRouter's Listeners are no longer a struct; use the static factory methods of the `VirtualNodeListener` class to obtain instances of them * **appmesh:** VirtualRouter accepts a list of listeners instead of a single listener ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a draft PR to resolve #9533
Takes an approach for creating protocol specific Gateway Routes as described in #10793
This is a draft as I am seeking feedback on the implementation and approach for creating per protocol variants of App Mesh Resources.
Before merging:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license