Do you have any articles/guides in the SST docs around what logic to apply for splitting a single app/service into multiple stacks (which are all deployed together)? To be clear, I’m not talking about splitting into multiple (micro)services here, but rather what things a developer should consider when deciding how to group different resources in multiple stacks. For example, I notice in @thdxr’s IdealStackPreview that the stacks are super-granular–just one resource per stack for many of them.

when I first started with CDK my instinct was to keep things all in one stack if possible because cross stack dependencies created weird, hard to debug issues. But this was a bad decision and pretty terrible for some of the reasons you listed and more specifically: • The more resources there are in a stack the longer it takes to rollback an error • Mixing stateful resources with resources you'd blow away means you can't blow away any stacks • The more granular the stack, the more can be skipped during deployment

yea, it’s getting the trade-offs right. Like when is too granular? I’ve been using CloudFormation for years and I still have to think about it. With Serverless Framework, I kinda shyed away from multiple granular stacks cos it was harder to do and had a lot more config overhead. SST definitely makes it much simpler to do, just need more clearer guidelines on when to do it

so far I haven't run into any issues with having a lot of stacks - but not saying I might not find something, still early. I know in CDK you deploy one stack at a time so your deploys will be slower if you have a lot. Some places where I'm aware of it causing issues today: 1. SST console, we make a request per stack to load metadata on start (and we're doing this in a particularly inefficient way) 2. The SST CLI also fetches things per stack so this will have a slight impact 3. Having a lot of cross stack dependencies makes it basically impossible to remove stacks from the UI because it's hard to know which other stacks need to be removed first 4. There are some issues with cross stack dependencies where if you remove a dependent stack, you get a confusing error as it tries to remove the export from the uneffected stack first. We have a patch in SST to "fake" an export to avoid this - it works well but it is a hack to be aware of

That’s a great list, thanks. None of those drawbacks look overly concerning and issues 1–3 look like they could be resolved in time with SST tooling fixes to console/CLI.

haha I'm still working on convincing myself!

one last q on this – you have separate Database and Cognito stacks (in the IdealStack demo). Any particular benefit in keeping them separate?

depends how you see it growing, Cognito stack you could start adding all kinds of triggers and things

ah yea of course, I forgot the requirement to keep Lambda triggers in same stack as user pool. makes sense