I would like receive some suggestion about the pro...
# help
g
I would like receive some suggestion about the project I’m working on, which is increasing the number of AWS resource very fast. In this moment it counts 417 resource on 500 available for the same stack. I decided to choose a mono-stack architecture to make easier dependencies resolution among resources, but it is not feasible anymore as solution, so I need to move to multi-stack architecture. My project is composed by: 1) 1 Admin angular app (sst.StaticSite) with its specific APIs (this APIs are most part of all defined resources and probably it will increase the number of services, they are almost 280 but it’s very unusual to growth more than 400) 2) 1 User angular app (sst.StaticSite) with their specific APIs (the count of defined resources for this APIs is low but in future for business purpose could be extended much more) 3) 2 Userpools (one for users and one for admins) 4) 1 Single DynamoDB table 5) 2 S3 bucket to let persistence for user and admin At the begining I was oriented to choose this solution: 1) Stack for Admin app: (app + api) 2) Stack for User app: (app + api) 3) Stack Core(Userpool, bucket, table) My doubts are: 1) Is it suggested in a multistack architecture includes in same stack app and api? Or it’s better to define an app as a per stack or join all apps in same stack? 2) Is it suggested to define a core stack as I described? Or it’s better to divide userpools from bucket and table? These type of resource are pretty immutable so I think could be good to keep them together.
a
I take a very multi-stack approach, to limit the blast radius if something goes wrong. Immutable resources (Cognito and it's pools and clients, DynamoDB and scaling, ....) have their own stacks and export values. StaticSite is its own thing, and then an API stack per domain. Small stacks make for small sst.Stack classes and better code organization. It's all down to preference, but I highly recommend at least splitting the data storage resources from the resource that are easily rebuilt.
f
Having a core stack makes sense. But it seems like the two User Pools don't qualify as core resources shared across the two apps. I’d keep the admin resources and user resources separate. I second @Adam Fanello that it's down to preference.
g
Thank you @Frank and @Adam Fanello, I found very useful your exeperiences. I think to set up this configuration: • main-data-stack (where I define the single table) • admins-backend-stack (Admins APIs and Stepfunctions) • users-backend-stack (Users APIs and Stepfunctions) • users-core-stack (Users userpool and bucket) • admins-core-stack (Admin userpool and bucket) • admins-app-stack (Angular app through sst.StaticSite) • users-app-stack (Angular app through sst.StaticSite) I think separate frontend stack from backend could improve deployment performance.