Hey @Frank, I wanna piggyback off your convo with @Akos on the above thread ^, mainly for clarification. It's very helpful because I'm migrating a monorepo with sls to use sst. How I've done it so far is that each service is a sst app under a monorepo. It's been tricky like for one I had to reference typescript types to the root because of hoisting to make testing work. But from the thread, as I understand, it can be just one sst app at the root and each service with its stack define in the

/lib

dir. Now if that's the case then there's no need for monorepo then, right? for each service to have its own

package.json

or does it still make sense for each service to have it's own

package.json

with lerna to control hoisting? Also, I'm using seed and I haven't deploy my sst app yet. But when adding a service on seed, is it looking for the service dir still or the stack file in

/lib

dir? Overall, I think an example of sst app that spans multiple services would be very helpful.

Hi @Sione we are not doing a good job laying out the “recommended” architecture. We will put together an example over the next few days!

Got it, that makes sense. Thanks. I think removing the monorepo piece just makes things more simpler. For context, what makes a service in seed vs a service in code structure from your guys point of view? I think with sls, the mapping made sense where a sls service in code is a service deployment in seed. But with sst that seems now to be different.

1 Serverless Framework project can only container 1 CloudFormation stack (serverless.yml). And you need to have multiple SLS projects to make up an app. On Seed, each serverless.yml file is a “Seed service”, so you will have multiple services on Seed. 1 SST project can have multiple CloudFormation stacks. So most likely you just need 1 SST project for the entire app. On Seed, each sst.json file is a “Seed service”, so you will have 1 service on Seed.

Ah that makes sense. It's definitely a shift of mindset but for the better. Thanks for clearing that part. So does the order of instantiating stacks in

/lib/index.js

guarantee any ordering or are all stacks being provisioned concurrently? I'm thinking of infra global resources that is passed in and shared between stacks like a database. Does sst handle resources dependencies in making sure resource that others are dependent on is created first? Or is that something that still fit for seed deploy phases that may guarantee order..

SST handles that. For example:

const apiStack = new ApiStack(app, "api")
const jobStack = new JobStack(app, "job", {
  httpApi: apiStack.httpApi
});

SST will deploy jobStack after apiStack

wow. that's pretty cool. I gotta say i'll miss the visual separation in seed between services when I put all my services into one sst app. One other case that comes to mind since separation now comes down to code level is if one stack failed on deployment does that prevent other independent stacks deployments or does sst or seed handle that as well..

i’ll miss the visual separation in seed

Under the resources page, you will still able to see each stack in there. But I hear you, if we see ppl need to deploy a specific stack from the pipeline page, we might expand and show all the services in an SST app.

if one stack failed on deployment does that prevent other independent stacks deployments

If 2 stacks are independent, they will be deployed in parallel. One failing will not stop the other one.

Awesome. That's good to know. you guys thought through it all. That clears up all my questions. thank you.