fix(apigatewayv2): integration class does not render an integration resource

[nija-at]

Routes on APIGateway V2 can integrate with different backends. This is
achieved by creating the CFN resource AWS::ApiGatewayV2::Integration
that is then referenced in the resource for the Route.

Currently, the IHttpRouteIntegration (and IWebSocketRouteIntegration)
interface represents a unique backend that a route can integrate with,
using the CDK "bind" pattern.
An integration can be bound to any number of routes but should be
rendered into a single instance of AWS::ApiGatewayV2::Integration
resource.
To achieve this currently, the HttpApi (and WebSocketApi) class
holds a cache of all integrations defined against its routes.

This is the wrong level of caching and causes a number of problems.

1. We rely on the configuration of the AWS::ApiGateway::Integration
   resource to determine if one already exists.
   This means that two instances of IHttpRouteIntegration can result
   in rendering only one instance of AWS::ApiGateway::Integration
   resource.

   Users may want to intentionally generate multiple instances of
   AWS::ApiGateway::Integration classes with the same configuration.
   Taking away this power with CDK "magic" is just confusing.

2. Currently, we allow using the same instance of
   IHttpRouteIntegration (or IWebSocketRouteIntegration) to be bound
   to routes in different HttpApi. When bound to the route, the CDK
   renders an instance of AWS::ApiGatewayV2::Integration for each API.

   This is another "magic" that has the potential for user confusion and
   bugs.

The solution is to KeepItSimple™.

Remove the API level caching and simply cache at the level of each
integration. This ensures that each instance of HttpRouteIntegration
(previously IHttpRouteIntegration) renders to exactly one instance of
AWS::ApiGatewayV2::Integration.

Disallow using the same instance of HttpRouteIntegration across
different instances of HttpApi.

fixes #13213

BREAKING CHANGE: The interface IHttpRouteIntegration is replaced by
the abstract class HttpRouteIntegration.

• apigatewayv2: The interface IWebSocketRouteIntegration is now
  replaced by the abstract class WebSocketRouteIntegration.
• apigatewayv2: Previously, we allowed the usage of integration
  classes to be used with routes defined in multiple HttpApi instances
  (or WebSocketApi instances). This is now disallowed, and separate
  instances must be created for each instance of HttpApi or
  WebSocketApi.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[nija-at]

cc @ayush987goyal

[otaviomacedo]

I don't know if it can happen with Stacks (maybe resolve() already takes care of that), but if the order of the fields change or if the presence or absence of whitespaces change, the hash will be different.

[nija-at]

Whitespace is not a problem here. Ordering maybe. I'll check.

[nija-at]

Ordering is actually a bigger problem here than I thought.

This PR is effectively not changing the logic of hashing. Just moving it to a different place (previously integration-cache.ts).

Do you mind if I take this on as a follow up PR? Easier to review as well.
I have a different solution in mind that effectively removes the need to hash.

[ayush987goyal]

Previously, we allowed the usage of integration
classes to be used with routes defined in multiple HttpApi instances
(or WebSocketApi instances). This is now disallowed, and separate
instances must be created for each instance of HttpApi or
WebSocketApi.

@nija-at If I am remember correctly, this was an explicit request from customers. I think this is something that the API Gateway console allows to do. That is, a single integration can be bound to multiple APIs and is typically created out of the scope of an API. Do you think this change might create a problem with that and/or customer might ask for it again?

[nija-at]

I think this is something that the API Gateway console allows to do. That is, a single integration can be bound to multiple APIs and is typically created out of the scope of an API

I don't know how that is possible since the AWS::ApiGatewayV2::Integration resource has ApiId as one of its properties.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-integration.html#cfn-apigatewayv2-integration-apiid

[ayush987goyal]

I don't know how that is possible since the AWS::ApiGatewayV2::Integration resource has ApiId as one of its properties.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-integration.html#cfn-apigatewayv2-integration-apiid

Yeah that's true. Maybe I am remembering something else. The change LGTM!

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: f0288a6
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

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).