0

I'm trying to migrate our Serverless Framework application to SST. We currently have 2 stacks that use the same REST API Gateway and all paths start with /v1.

Following the SST doco here I was able to add routes from two stacks into one API Gateway. However, when using the same path part i.e. /v1 the deployment fails and I get an error message saying

Another resource with the same parent already has this name: v1 (Service: ApiGateway, Status Code: 409, Request ID: ...)

Ok, I thought I would need to reference the route resource /v1 and use the importedPaths property on ApiGatwayV1's cdk property, also shown in the doco example.

export function Api2({ stack }: StackContext) {
  const { api } = use(Api1);

  const restApi = RestApi.fromRestApiAttributes(stack, "api", {
    restApiId: api.cdk.restApi.restApiId,
    rootResourceId: api.cdk.restApi.restApiRootResourceId,
  });
  const v1 = restApi.root.resourceForPath("/v1");

  new ApiGatewayV1Api(stack, "second-api", {
    cdk: {
      restApi,
      importedPaths: { "/v1": v1.resourceId },
    },
    routes: {
      "GET /v1/todo-list": "packages/functions/src/todo.handler",
    },
  });
}

But no, I still run into the same issue. Debugging the v1.resourceId reveals that the id looks like a temporary/internal reference rather than an AWS id ${Token[TOKEN.781]}, but I would have expected it would be resolved?

SST deploys the stacks in one go whereas our two Serverless stacks are deployed using two separate commands. The 2nd stack would be able to retrieve the real resource id from the 1st stack's output, so maybe that is why it's succeeding.

Anyway, I kinda think that having a common base route/path would not be such an exotic construct.

To quickly reproduce and play around with the setup, I've created a new SST project and modified it so it reflects our setup: https://github.com/robbash/multi-stack-apigw

Thanks in advance, cheers.

robbash
  • 985
  • 10
  • 21
  • I can add a full answer later, but you can use stage variables to accomplish what you are trying to do. – Pharmakon Jul 06 '23 at 23:01
  • @Pharmakon thanks for your comment. Technically, I'd see this as a workaround. I ended up using another workaround for now by using custom domain names and `v1` as path in API mappings. For as long as there is no real solution, it might be worth writing up your comment as an answer. I'll likely add mine later too. Cheers – robbash Jul 07 '23 at 07:43

0 Answers0