ApiGatewayV1 and ApiGatewayV2 should be restructured to allow route specific settings (throttling etc.)

[vvashisht]

ApiGatewayV2 constructor creates the stage automatically and therefore adding route specific settings does not work as the intended route keys haven't been created yet. And route keys can't be created without ApiGatewayV2 itself. This creates an unnecessary cyclic dependency. This can be avoided by necessitating an explicit stage() / deploy() method after routes have been added. Additionally, routes would need to be exposed as nodes so that an explicit dependency can be added on them before staging/deploying.

ApiGatewayV1 does have an explicit deploy() method but does not expose the already created stage and routes in nodes. If it did, one could use aws.apigateway.MethodSettings to add route specific settings with an explicit dependency on stage and routes.

[fwang]

hey @vvashisht I haven't tried this, but can you transform the stage to define route settings (ie. throttling), and also disable autoDeploy. Then manually create a deployment?

[vvashisht]

That's sort of what I ended up doing. I haven't taken into account the #4498 fix yet, but this is what I did:

When creating ApiGatewayV2, I specify transform.stage options to change stage name to 'dummy' and autoDeploy to false.
This ensures that the auto-created stage is disabled / dummy and not deployed.

I then add routes to this ApiGatewayV2 instance and keep track of their instances.

Finally, I 'deploy' this ApiGatewayV2 where I create:

• A new Stage using the pulumi resource with name '$default' and specify route specific settings (throttling etc.)
• Mark autoDeploy true for this stage
• I hand copied the access log format from ApiGatewayV2 code
• Add all route instances from before to this stage's dependsOn custom resource option (and parent as the api gateway instance)
• A new DomainName using pulumi (the domain is already created at this point)
• A new ApiMapping to map this new Stage and the DomainName just created

I might be able to simplify the last two steps because of the fix for #4498.

I had to resort to a dummy stage because I can neither prevent its creation when instantiating ApiGatewayV2 nor specify route specific settings in the transform because then, the deployment throws an error where it can't find the route keys to routes as they haven't been created yet.

What I haven't tried (or forgot if I did; I was trying a lot of things) is to disable autoDeploy and specify route specific settings when creating ApiGatewayV2, add routes to it, then ... how do I deploy this stage? I haven't explored aws.apigatewayv2.Deployment yet. And I can't modify the stage during the deployment. I need to experiment to figure out if there is a way forward in this approach or not. And unfortunately, at least for now, I don't have the bandwidth. But I'll come back to it soon.

I'll say this though, I understand the convenience of auto-created $default stage, but I'm still of the opinion that ApiGatewayV2 would be more future-proof and open-ended if:

• The stage name $default isn't hard-coded (in methods, createStage and createDomainMapping). $default should be the default value, but it should be customizable
• The sequence of creating the api gateway > stage > domain > api mapping isn't completed in the ApiGatewayV2 constructor, and instead follows the ApiGatewayV1 model of explicitly invoking a deploy method

[vvashisht]

I tried what you suggested.

Set autoDeploy to false and specified routeSettings in transform.stage when instantiating ApiGatewayV2

It doesn't work, I get the same error:
Unable to find Route by key GET /xxx/xxx within the provided RouteSettings

Apparently AWS doesn't care if a stage is deployed or not; if you're going to specify route specific settings in the stage, those routes need to be created first. It's hard to say that this is unreasonable.

I didn't proceed further with this experiment for now.