-
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(apigatewayv2-integrations): EventBridge PutEvents integration #13017
feat(apigatewayv2-integrations): EventBridge PutEvents integration #13017
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.
Thanks for submitting this PR @shankben!
My initial question is around the commit description. The issue you've marked as 'fixes' refers to step functions. However, this PR is only supporting eventbridge putevents integration. Can you remove the reference?
Further, it's not clear to me why all of these are considered breaking changes. Adding a property to an enum is not a breaking change, nor is making a mandatory property optional. Can you review these and update?
Pull request has been modified.
In order to propagate necessary configuration parameters to the AWS service integration type, the following changes were introduced: - Added AWS_PROXY enum property to HttpIntegrationType - Added nullable integrationSubtype and nullable requestParameters types to HttpIntegrationProps - Added nullable credentialsArn, nullable integrationSubtype, and nullable requestParameters in HttpRouteIntegrationConfig - Changed integrationUri in HttpIntegrationProps to a nullable type as AWS service integrations do not require this field per the CloudFormation spec - Bubbled up nullable credentialsArn in HttpIntegrationProps - Sorted properties in call to new CfnIntegration in constructor of HttpIntegration - Introduced private method renderRequestParameters to convert L2 requestParameters to CloudFormation compantible property names - Modified uri in HttpRouteIntegrationConfig to a nullable type as AWS service integrations do not require this field per the CloudFormation spec - Modified constructor of HttpIntegration to throw an Error if AWS_PROXY parameters are misconfigured
e763814
to
0079639
Compare
…y-apigateway2-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.
Thanks for submitting this PR. Please see my first round of comments below.
packages/@aws-cdk/aws-apigatewayv2-integrations/lib/http/eventbridge.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-apigatewayv2-integrations/lib/http/base-types.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-apigatewayv2-integrations/lib/http/eventbridge.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-apigatewayv2-integrations/lib/http/aws/integration.ts
Outdated
Show resolved
Hide resolved
…y-apigateway2-integration
Co-authored-by: Niranjan Jayakar <[email protected]>
…om:shankben/aws-cdk into shankben/aws-proxy-apigateway2-integration
Pull request has been modified.
…bridge.ts Co-authored-by: Niranjan Jayakar <[email protected]>
…om:shankben/aws-cdk into shankben/aws-proxy-apigateway2-integration
…bridge.ts Co-authored-by: Niranjan Jayakar <[email protected]>
…om:shankben/aws-cdk into shankben/aws-proxy-apigateway2-integration
…ine apigatewayv2 requestParameters
… AwsServiceIntegrationSubtype directly
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
Apologies for the delay here @shankben. There are some other areas we're focusing on at the moment, and this is not at the top of our priority. Letting you know so you're aware of the response times here.
My main concern is about the modeling (see comment below), and I think we need to think a little deeper about what the correct modeling for this would be from the customer experience.
Given that this is the first AWS private integration, it's important that we get the model correct. This will set the right expectation for others that follow.
I would suggest first writing down the customer experience for 2-3 of these integrations and see how they feel to the user based on real use cases, i.e., pin down what would be a delightful API experience for customers.
eventBus, | ||
requestParameters: { | ||
source: 'test', | ||
detail: '$request.body.result', |
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 thought this needs to be a valid JSON string, no?
/** | ||
* The EventBridge PutEvents request parameters. | ||
* @see https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html | ||
*/ | ||
readonly requestParameters: EventBridgeIntegrationRequestParameters; | ||
} |
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.
As I go through this, something feels incorrect or odd here in terms of class modeling.
For one, the targetAction
allows for other EventBridge APIs to be invoked but EventBridgeIntegrationRequestParameters
is very specific to the PutEvents
API.
It's not clear to me if this class should be EventBridgePutEventsIntegration
. I'm aware this is conflicting with my previous comment - #13017 (comment). Perhaps we may have to go back to the previous model.
Second, the resources
option allows customers to pass a set of ARNs. I would've assumed this would be the ARN of the APIGateway resource but it looks like this is configurable. When and why would this be done?
I suppose more generally - what is/are the use cases that customers are expected to use this integration?
Finally (probably least important here), we probably do not need an additional nested requestParameters
section. Flattening it might suffice.
This PR requires a lot more work to get the API ergonomics and design right. It's not clear to us that this is our highest priority at the moment, given the low interest levels in the original issue and PR. I'm going to assign myself from this PR, since we are unable to work on it immediately. |
924c117
to
ebfd5f2
Compare
This PR has been deemed to be abandoned, and will be closed. Please create a new PR for these changes if you think this decision has been made in error. |
Related to: #11947
In order to propagate necessary configuration parameters to the AWS service integration type, the following changes were introduced:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license