-
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(apigateway): WebSocketIntegrationResponse
implementation
#29661
base: main
Are you sure you want to change the base?
feat(apigateway): WebSocketIntegrationResponse
implementation
#29661
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.
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.
// FIXME change to a warning? | ||
throw new Error('Setting up integration responses without setting up returnResponse to true will have no effect, and is likely a mistake.'); |
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.
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 feel like a warning would be more suitable here if it's something that's possible to do from the web console, is there a very strong reason you think we should throw an exception instead?
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 see a stronger reason to allow this in the web console, say if you want to add responses first, before enabling returnResponse
. With IaC, you can just block comment both the integration responses and the property. I don't mind just showing a warning, an exception just seemed like it would save people time debugging something that could could be easily missed at deploy time
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.
Rather than doing this validation after the fact, we should structure these inputs so that they are tightly coupled and so that users can't do 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.
Ultimately, what I think should be done here is to deprecate the returnResponse
field and update it to response
that takes in a enum like class with two options: DEFAULT
, which is what it's doing now, and customResponse()
that is a function that creates all the stuff you're creating in this PR. What do you think?
/** | ||
* Integration response ID | ||
*/ | ||
public readonly integrationResponseId?: 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.
I assume this was added in anticipation of an implementation of integration responses, but serves no purpose and cannot store multiple responses
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.
Technically, we need to deprecate this, not delete it. While it doesn't actually do anything, the removal is a breaking change. This is a stable module so we can't allow it.
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.
Also, can we get access to this id in this scope? If so, why not just set it?
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 main issue is that there can be multiple integrationResponseId
, it would need to be a string[]
to be usable. I don't think setting it to the first value is worth the confusion. I can leave it up and just @deprecrate
it, but again, I think it's needlessly confusing given it was never implemented
// FIXME any better way to generate a unique id? | ||
Names.nodeUniqueId(this.integration.node) + slugify(responseProps.responseKey.key) + 'IntegrationResponse', | ||
{ ...responseProps, integration: this.integration }, | ||
); |
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.
Unsure this is the best way to generate this ID, feedback would be appreciated
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Co-authored-by: paulhcsun <47882901+paulhcsun@users.noreply.github.com>
Co-authored-by: paulhcsun <47882901+paulhcsun@users.noreply.github.com>
…ebsocket-integration-response
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.
Thank you for your contribution! This is a great start! I have several comments inline where I think we can make this experience a little more strongly typed and a bit cleaner for the user, especially if the user is working in one of our other supported target languages.
* @default - No request template provided to the integration. | ||
* @see https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-mapping-template-reference.html | ||
*/ | ||
readonly requestTemplates?: { [contentType: string]: 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.
I think we could make this more strongly typed. From the link you added, we know all of the valid parameters a user can add here and some of the valid values for those
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 not sure what you mean by improving the type strength, given the key can be any MIME type and the value can be any string, which may contain one of the linked parameters.
We could create a builder/helper class to generate those values but that seems like a bit of overkill. An parameter enum would also be insufficient given some of them are functions, e.g. $input.json('$.pets')
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.
Moving this discussion to https://github.com/aws/aws-cdk/pull/30622/files#r1649600512
* | ||
* @default - No response parameters | ||
*/ | ||
readonly responseParameters?: { [key: string]: 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.
There's a lot of description above of how the user must format these and which values they can be. Can we provide any further constraints here or do some of the formatting for them so that they aren't on their own here?
// FIXME change to a warning? | ||
throw new Error('Setting up integration responses without setting up returnResponse to true will have no effect, and is likely a mistake.'); |
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.
Rather than doing this validation after the fact, we should structure these inputs so that they are tightly coupled and so that users can't do this.
new WebSocketIntegrationResponse( | ||
options.scope, | ||
// FIXME any better way to generate a unique id? | ||
Names.nodeUniqueId(this.integration.node) + slugify(responseProps.responseKey.key) + 'IntegrationResponse', |
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 would use Names.uniqueResourceName
instead. It's less likely to cause collisions and to ensure the name has the proper length. This naming could result in names being too long and failing at deployment time.
/** | ||
* Integration response ID | ||
*/ | ||
public readonly integrationResponseId?: 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.
Also, can we get access to this id in this scope? If so, why not just set it?
* The abstract class that two-way communication route integration classes | ||
* with customized responses will implement. | ||
*/ | ||
export abstract class CustomResponseWebSocketRoute extends WebSocketRouteIntegration { |
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 this necessary? Are there WebSocketRouteIntegration
types that can't take in a custom response?
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, WebSocketLambdaIntegration
is the only integration that does not support custom responses, see #29661 (comment)
* | ||
* @default - No response templates | ||
*/ | ||
readonly responseTemplates?: { [contentType: string]: 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.
What are the valid content types? Rather than this being a key value pair, can we make this more strongly typed? Like maybe a class that is ResponseTemplate.applicationJson(...)
and then the parameter is responseTemplates: ResponseTemplate[]
?
* | ||
* @see https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-integration-responses.html | ||
*/ | ||
export interface InternalWebSocketIntegrationResponseProps { |
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.
Instead of making this a props interface, can you make this a class with the first input in the constructor being the responseKey
and then the rest props? I think that will be a bit cleaner than the current experience.
I forgot to add, you added some changes that were actually unrelated to this implementation. Can you please separate those out into a separate PR? |
Co-authored-by: Kendra Neil <53584728+TheRealAmazonKendra@users.noreply.github.com>
Pull request has been modified.
…ebsocket-integration-response
|
…ebsocket-integration-response
…ebsocket-integration-response
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This PR is pending for community review now. |
Issue # (if applicable)
None as far as I could tell, related to #29562.
Reason for this change
While it is possible to use the L1
CfnIntegrationResponse
construct, it's not trivial given theWebSocketRouteIntegration
are currently bound to theWebSocketIntegration
on the fly.Description of changes
WebSocketIntegrationResponse
constructWebSocketIntegration
s (capable of settingIntegrationResponse
) aresponses
config prop, as well as aaddResponse
method. This allows me to check that there are no repeatresponseKey
s, and thatreturnResponse
is active if there areresponses
setCustomResponseWebSocketRoute
abstract class was created to isolateWebSocketLambdaIntegration
, which does not support response customizationWebSocketIntegrationResponseKey
helper class to access common and to generate customresponseKey
sDescription of how you validated changes
Unit tests were added/modified, and existing integration files were extended to include responses
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license