This is a somewhat fundamental question so bear with me. I'm thinking about if and how we should be dividing up our stacks. Currently we have a single stack and some logic inside of that stack to add resources based on which modules a customer has purchased. I.e. there are some core services and then some optional ones. Each customer has its own AWS account. Would it be an improvement to create a separate stack for each optional module, then perform the logic about which stacks to create in the index.ts entrypoint? If so, I can see this adding some complexity in regard to the sharing of resources, so if this would be a better approach, why is it better?

This is the type of thing I like thinking about but I've been attempting to travel for the past 18 hours so I'll get back to you

No worries, thank you

Going through a similar thing atm with a project. Generally speaking all of the modules are currently available to all customers. But there is some thought to make some optional and lower pricing for those that don't need all modules. Currently it's also a single stack. My initial thought is to create a base stack that host all the core modules that is required for everyone and then based on the customer then add in each module to that stack. Or maybe have a second stack that is mainly just all the optional ones

Thanks Justin. Yeah, that's exactly the decision I'm trying to make. Since the optional modules need to make use of shared resources like auth, RDS and DynamoDB, it does complicate things as they need to get hold of those resources whereas, when they're all in the same stack, that's simpler. I don't yet appreciate how big the trade-off is though

Yea for sure. One of the considerations we're deciding on is also the fact that we are getting close to the resource limits. Although a bunch of it is to do with our pipelines which we can probably optimize as well.

@thdxr did you get some time to think about this yet? No worries if not

My suggestion would be to keep things in a single stack. When I first started I was using just a single stack for everything (mostly because I didn't really understand stacks). Then I shifted to multiple stacks thinking it was more "correct". Now looking back I think I was happier with my single stack setup - there's not a ton of advantage with having multiple stacks outside of things looking a certain way inside AWS's UI. And there's all sorts of cross-stack weirdness that can happen with one stack deleting but another not or cyclical references. Here's a pattern I was using

export class Stack extends sst.Stack {
  constructor(scope: <http://sst.App|sst.App>) {
    super(scope, "Stack")

    const vpc = Vpc(scope, this)
    const database = Database(scope, this, { vpc })
  }
}

function Vpc(scope: <http://sst.App|sst.App>, stack: sst.Stack) {
  // Do vpc
  return {
    subnets,
    etc,
  }
}

type DatabaseProps = {
  vpc: ReturnType<typeof Vpc>
}

function Database(scope: <http://sst.App|sst.App>, stack: sst.Stack, props: DatabaseProps) {
  // Do database
  return {
    rds
  }
}

Thanks Dax, that's pretty much how I have it at the moment and it's reassuring that we're thinking along the same lines, and that I don't have to think about how to split it up