You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chore(apigatewayv2): integration api re-organization (#17752)
There are three major changes.
`HttpRouteIntegration` (and its sibling `WebSocketRouteIntegration`)
creates a CDK construct (`HttpIntegration` and `WebSocketIntegration`)
as part of its bind operation. The id to this CDK construct is
determined by hashing the results of the bind.
Using hashes makes the construct id fragile/sensitive, consequently the
CFN resource's logical id fragile.
The fragility comes mainly from the question - have we hashed all of the
expected properties that should be hashed, and nothing extra?
If we have not hashed properties that should be there, or hashed too
much, we end up with a hash change, hence resource replacement that
is unexpected.
This commit changes this approach and asks the user to provide the
construct's id. This is more aligned with the current CDK expectation
that users provide an id when initializing constructs.
We just don't have a good way to validate that our hashing is accurate,
so let's not do it at all. This change makes the user provide a unique
name within a scope, which is already a standard requirement for CDK
constructs.
Secondly, the ergonomics of specific integration implementations, such
as, `LambdaProxyIntegration`, `HttpAlbIntegration`, etc. is modified so
that the integrating primitive is moved out of the 'props', and to the
constructor.
The API ergonomics of this feels much better than having to always
provide a 'props'.
Since this package contains constructs around both http api and
websocket api, the convention to follow is that all classes specific to
the former will be prefixed with `Http` and the latter will be prefixed
with `WebSocket`.
Bring the integration classes `LambdaProxyIntegration` and
`HttpProxyIntegration` in line with this convention. These are renamed
to `HttpLambdaIntegration` and `HttpUrlIntegration` respectively.
BREAKING CHANGE: The `HttpIntegration` and `WebSocketIntegration`
classes require an "id" parameter to be provided during its initialization.
* **apigatewayv2-integrations:** The `LambdaWebSocketIntegration` is now
renamed to `WebSocketLambdaIntegration`. The new class accepts the
handler to the target lambda function directly in its constructor.
* **apigatewayv2-integrations:** `HttpProxyIntegration` and
`HttpProxyIntegrationProps` are now renamed to `HttpUrlIntegration`
and `HttpUrlIntegrationProps` respectively. The new class accepts the
target url directly in its constructor.
* **apigatewayv2-integrations:** `LambdaProxyIntegration` and
`LambdaProxyIntegrationProps` are now renamed to
`HttpLambdaIntegration` and `HttpLambdaIntegrationProps` respectively.
The new class accepts the lambda function handler directly in its
constructor.
* **apigatewayv2-integrations:** `HttpAlbIntegration` now accepts the
ELB listener directly in its constructor.
* **apigatewayv2-integrations:** `HttpNlbIntegration` now accepts the
ELB listener directly in its constructor.
* **apigatewayv2-integrations:** `HttpServiceDiscoveryIntegration` now
accepts the service discovery Service directly in its constructor.
* **apigatewayv2-authorizers:** `UserPoolAuthorizerProps` is now
renamed to `HttpUserPoolAuthorizerProps`.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
0 commit comments