-
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): change VirtualRouter's Listener to a union-like class #11277
Conversation
Noticed a failure with the ECS patterns library. Will get a fix for this soon |
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.
Gotta say, I don't see the point of this abstraction currently. Unless it's in preparation for more listener properties in the future? But if that's the case, we should have a separate interface per static factory method right now (it's fine if they're empty and just extend RouterListenerProps
today).
Also, you've missed updating the ReadMe, and noting the breaking change to VirtualRouter
(going from listener
to listeners
).
/** | ||
* Returns a TCP Listener for a VirtualRouter | ||
*/ | ||
public static tcpGatewayListener(props: RouterListenerProps = {}): VirtualRouterListener { |
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 any chance any of these will have protocol-specific properties later? Because frankly, in its current form, I don't think this abstraction is buying us anything...
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.
Virtual Routers specifically do not currently have any protocol specific properties. The main reason I think we should do this change is for consistency. If we have listeners on Virtual Nodes and Virtual Gateways, having listeners for your virtual routers that are defined in a different way seems like poor UX. If you don't think it is worth the change, we can scrap this PR.
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.
Consistency is not a bad argument.
How about this. Let's make port?: number
an optional positional argument to each of the static factory methods in this class, and get rid of RouterListenerProps
completely. Then, creating a Listener will be as simple as calling VirtualRouterListener.http(8081)
. I think that's a reasonable compromise between consistency and ease of use.
Thoughts on this idea?
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.
Sounds good to me. Simpler for sure. Made the update
/** | ||
* Protocol the listener implements | ||
*/ | ||
protected protocol: Protocol = Protocol.HTTP; |
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 instead make the base class abstract with a public abstract readonly protocol: Protocol
property, and then each of the subclasses will implement protocol
?
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, we can further simplify this by only having one subclass for all 4 protocols.
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 replies to the questions. I think it makes sense to do this PR, just with some slight tweaks.
/** | ||
* Represents the properties needed to define Listeners for a VirtualRouter | ||
*/ | ||
export interface RouterListenerProps { |
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.
These should be *Options
, so RouterListenerOptions
. *Props
are reserved for construction properties of Constructs. Apologies I did not notice this before (we'll probably have to go back and change a few of these in other places in the AppMesh module).
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.
No problem. Should updating other places be done in this in this PR or separate?
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.
Let's keep it separate.
/** | ||
* Returns a TCP Listener for a VirtualRouter | ||
*/ | ||
public static tcpGatewayListener(props: RouterListenerProps = {}): VirtualRouterListener { |
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.
Consistency is not a bad argument.
How about this. Let's make port?: number
an optional positional argument to each of the static factory methods in this class, and get rid of RouterListenerProps
completely. Then, creating a Listener will be as simple as calling VirtualRouterListener.http(8081)
. I think that's a reasonable compromise between consistency and ease of use.
Thoughts on this idea?
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! We're almost there, a few comments.
Also, missing ReadMe changes.
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.
LGTM!
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.
One small nitpick.
packages/@aws-cdk-containers/ecs-service-extensions/lib/extensions/appmesh.ts
Outdated
Show resolved
Hide resolved
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.
Can the PortMapping
interface be removed with this change?
I guess no, because it's still used in the current version of |
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). |
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 themBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license