I'm trying to understand why the

ApiGatewayV1Api

construct feels the need to 1. Prefix the

restApiName

with the stage, even though the stage is being set in the gateway which means the API Gateway instance can be reused with other stages 2. Overwrites me attempt to set the

restApiName

myself. Are there any specific reasons, or should I just file a bug report and fix it?

Hey @kierans777, stages in SST is not the same thing as API Gateway’s REST API stages. For each stage in SST, a new API Gateway REST API project is created.

@Frank Thanks for the answer 🙂 How's that different to having a REST API with a name, and a APIGW stage being able to be deployed to different AWS accounts?

hey @kierans777, are you currently creating 1 APIGW instance and creating APIGW stages in different AWS account?

@Frank No. Each region gets an APIGW instance with a

prod

stage. However I attach different APIGW stages (dev, test, etc) as required to an APIGW instance. The approach you've taken is similar to what AWS Amplify does. It also deploys a separate APIGW instance for each logical env (dev, test, prod, etc) with a single APIGW stage. So with SST if I deploy dev, test and prod as SST stages I get three APIGW instances, each with only one stage. I just don't understand the need to create multiple APIGW instances when you can create one per API and use the APIGW stages to manage the logical envs/stages you want to deploy.

@kierans777 Gotcha! This design decision is made to ensure each environment is as self-contained, as standalone as possible. When multiple environments share the same APIGW instance, one environment needs to act as the owner, resulting in inter-environment dependencies.

@Frank Some good points. I guess for my non-SST project, because there's always going to be a prod stack in the region/account I'm testing in so it doesn't bother me. However I have noticed that it's the first stack deployed that creates the APIGW instance and attaches the stage. Even if that stack is undeployed if another stage is attached to the APIGW then the APIGW instance hangs around. So that removes any inter-environment dependencies somewhat. However from an organsiational perspective it could be more confusing (although more efficient) to reuse the APIGW instance with all the intricacies. If I ever port my CDK project to SST it's something I'll have to worry about.