SST: How to deploy multiple stacks using the same RestApi with common base path

Question

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.

Answer 1

Finally I was able to solve this issue. Maybe it's a little bit too late for you but it may help others.

Not Working code:

  const  api = new ApiGatewayV1Api(stack, 'api', {
  cdk: {
    restApi: RestApi.fromRestApiAttributes(stack, 'RestApi', {
      restApiId: process.env.REST_API_ID ?? '',
      rootResourceId: process.env.REST_API_ROOT_RESOURCE_ID ?? ''
    }),
    importedPaths: {
      '/api/admin': process.env.REST_API_ADMIN_RESOURCE_ID ?? '',
      '/api': process.env.REST_API_API_RESOURCE_ID ?? ''
    }
  },
  routes: {
    'POST /api/newsletters/subscriptions/unsubscribe': {
      ...
    },
    'POST /api/newsletters/subscriptions/subscribe': {
      ...
    },
  }

Still not working code:

  const  api = new ApiGatewayV1Api(stack, 'api', {
  cdk: {
    restApi: RestApi.fromRestApiAttributes(stack, 'RestApi', {
      restApiId: process.env.REST_API_ID ?? '',
      rootResourceId: process.env.REST_API_ROOT_RESOURCE_ID ?? ''
    }),
    importedPaths: {
      '/api/admin': process.env.REST_API_ADMIN_RESOURCE_ID ?? '',
      '/api/newsletter': process.env.REST_API_API_RESOURCE_ID ?? ''
    }
  },
  routes: {
    'POST /api/newsletters/newsletters/subscriptions/unsubscribe': {
      ...
    },
    'POST /api/newsletters/newsletters/subscriptions/subscribe': {
      ...
    },
  }

The API Gateway is right, but the Lambda trigger is not correct because it searches for newsletters/newsletters: API Gateway api list

Solution:

  const  api = new ApiGatewayV1Api(stack, 'api', {
  cdk: {
    restApi: RestApi.fromRestApiAttributes(stack, 'RestApi', {
      restApiId: process.env.REST_API_ID ?? '',
      rootResourceId: process.env.REST_API_ROOT_RESOURCE_ID ?? ''
    }),
    importedPaths: {
      '/api/admin': process.env.REST_API_ADMIN_RESOURCE_ID ?? '',
      '/api': process.env.REST_API_API_RESOURCE_ID ?? ''
    }
  },
  routes: {
    'POST /api/newsletters/subscriptions/unsubscribe': {
      ...
    },
    [[INSERT ONE API AT THE TIME]]
  }

If you deploy one API at the time, the deploy will go successful and you have your intended result. Yes, it's a workaround but the final result is what we needed!

Hope it helps