docs: add migration guide for API Gateway & Lambda #1308
Conversation
| 2. Create an instance of the `CfnDomainName` and `CfnBasePathMapping` classes in your template. | ||
|
|
||
| In order to avoid downtime, pass the logical id of your `AWS::ApiGateway::DomainName` into the `CfnDomainName` class and | ||
| the logical id of the `AWS::ApiGateway::BasePathMapping` into your `CfnBasePathMapping` class. | ||
|
|
||
| Ensure that the properties passed into these classes line up with those specified in your CloudFormation template. |
There was a problem hiding this comment.
This is a lot! Is it worth us creating a L2 construct that does this?
There was a problem hiding this comment.
Yeah, it's a bit awkward, but it doesn't end up being that much code:
const cfnDomainName = new CfnDomainName(this, "ApiDomainName", {
domainName: props.domainName,
certificateArn,
});
new CfnBasePathMapping(this, "ApiMapping", {
domainName: cfnDomainName.ref,
restApiId: yamlDefinedResources.getResource("SaveForLaterApi").ref,
stage: props.stage,
});Were you thinking the L2 construct would just be used for removing boilerplate or were you intending to use it to help in some other way?
There was a problem hiding this comment.
Were you thinking the L2 construct would just be used for removing boilerplate or were you intending to use it to help in some other way?
Just boilerplate. Agree though, it's not too bad as is.
| Note that you **must** use the `functionNames` parameter for this to work. | ||
| The alternative strategy (which uses `lookupByTags`), will not work with the dual-stack approach. |
There was a problem hiding this comment.
Could we do something similar to the dual-ASG trick here? As in, add an identifier tag to the new resources to help Riff-Raff distinguish between them?
There was a problem hiding this comment.
Yes, I think this would be possible.
However using the names actually seems a lot more straightforward than following the slightly awkward process that we use to cope with having two ASGs with the same tags. See here & here.
So I'm unsure if we really want to introduce another way of doing things here (especially as lookupByTags seems to be false by default anyway).
What does this change?
Add a migration guide for the
GuApiLambdaandGuApiGatewayWithLambdaByPathpatterns.How to test
This is the process that I followed for the
mobile-save-for-latermigration:The next time we follow these docs we should make any necessary corrections (I've probably forgotten something!).
How can we measure success?
Users can attempt self-service migrations to two more GuCDK patterns!
Have we considered potential risks?
Yes, I have tested this migration path for the
GuApiGatewayWithLambdaByPathpattern but not theGuApiLambdapattern. I'm pretty confident that the process will be the same, but I can't be 100% sure as I haven't tested it.Checklist
Footnotes
Consider whether this is something that will mean changes to projects that have already been migrated, or to the CDK CLI tool. If changes are required, consider adding a checklist here and/or linking to related PRs. ↩
If you are adding a new construct or pattern, has new documentation been added? If you are amending defaults or changing behaviour, are the existing docs still valid? ↩