Serverless framework AppSync service with custom split stacks

serverless.yml

custom:
  splitStacks:
    nestedStackCount: 50
    perFunction: false
    perType: false
    perGroupFunction: false

stacks-map.js

module.exports = (resource, logicalId) => {
    console.log(resource.Type, logicalId);
  
    // Keep the deployment bucket with default setup
    if( logicalId.startsWith('ServerlessDeploymentBucket') || resource.Type == 'AWS::Lambda::Permission'){
        return 
    }

    if( (resource.Type == 'AWS::S3::Bucket' || resource.Type == 'AWS::S3::BucketPolicy') ){
        return { destination: 'S3GroupStack', allowSuffix: true, force: true };
    }
  
    if ( resource.Type == "AWS::Logs::LogGroup" && !logicalId.endsWith('GraphQlApiLogGroup') ) {
        return { destination: 'LogGroupsStack', allowSuffix: true, force: true };
    }
  
    // Appsync specific resources
    if( resource.Type == 'AWS::AppSync::GraphQLSchema' ||
        resource.Type == 'AWS::AppSync::FunctionConfiguration' || 
        resource.Type == 'AWS::AppSync::DataSource' || 
        resource.Type == 'AWS::AppSync::Resolver' ){
        return { destination: 'AppSync', allowSuffix: true, force: true };
    }    

    // Falls back to default
};

Some background: Initially the project was created with two stacks 1) VPC-based Stack and 2) Serverless Stack. This application is currently in the testing phase and has close to 600 resources. The application uses a bunch of AWS services like Aurora, RDS Proxy, Lambda, Appsync, Private API Gateway, Public API Gateway, HTTP API Gateway, Step Functions, DynamoDB, Pinpoint, etc.

With time the serverless framework project grew too large and we reached 499 resources sooner than expected. Structurally we should separate the resources based on the feature set, but still, we wanted to keep the Appsync-related resources in a single place.

While doing the stack splitting, it was expected that we would run into a set of dependency issues. After some debugging, we were able to create nested stacks. Please be aware that doing a split at a late stage will require a fresh deployment as the existing stack will not be able to migrate resources easily. We are still in the testing phase, so it is possible to deploy new stage and migrate the Route53 URLs to point to the new stage.

Likely errors:

• Circular dependencies - This you can easily understand and resolve by going through your resources and keeping the related resources in the same stack.
• Resource already exists in another stack - This will come if you are trying to deploy the changes on the existing stage that is not using split stack or has a different stack structure. For me, the closest solution was to deploy a new stage.