just dumping this here in case it helps anyone. th...
# help
just dumping this here in case it helps anyone. this is my SST monorepo structure. my convention is, anything named “libs” is shared stuff. so I renamed the default “libs” to “infra”. I have a core stack that everything depends upon, then other stacks that build on that.. for now, just api is done, but others will follow (media-processor, etc)
Copy code
├── README.md
├── cdk.context.json
├── infra
│   ├── api
│   │   ├── appsync.ts
│   │   ├── graphql-schema.gql
│   │   ├── rest-routes.ts
│   │   └── stack.ts
│   ├── core
│   │   ├── auth.ts
│   │   ├── buckets.ts
│   │   ├── cloudfront.ts
│   │   ├── database.ts
│   │   ├── ec2-tunnel.ts
│   │   └── stack.ts
│   ├── index.ts
│   └── libs
│       ├── get-ssm-parameter.ts
│       ├── route-helpers.ts
│       └── types
│           └── infra.ts
├── package.json
├── public_key.pem
├── src
│   └── services
│       ├── auth
│       │   ├── cognito-email-sender.ts
│       │   └── package.json
│       ├── graphql
│       │   ├── package.json
│       │   └── tracking.ts
│       └── rest-api
│           ├── functions
│           │   ├── create-thing.spec.ts
│           │   ├── create-thing.ts
│           │   └── get-things.ts
│           ├── package.json
│           ├── routes
│           └── util
├── sst.json
├── tsconfig.json
└── yarn.lock

13 directories, 29 files
hmm. I should make a GitHub template, maybe
@Sam Hulick Yeah that’d be great! @thdxr@Jay, this 1 core stack + N dependent stacks is a common pattern we’ve seen. Does it make sense to create an SST example with this? I think we should have 1 example for every common setup, and each example comes with a starter.
i really like how your organized your infra. my schema.graphql is currently under src, gonna copy yours.
question - why keep your individual services as individual repo’s each with a package.json? i used that method with the serverless package system deployed on SEED, but only because i wanted them deployed as individual stacks. but SST allows stacks to be separate without using the monorepo approach within the services dir. not sure if my choice was best practice or not, so i’m wondering if you can share the reason/benefit for it. thanks!
sure! those are yarn workspaces. so the benefit is that I can install packages only usable by those folders via
yarn workspace rest-api add some-package
the actual package is installed in
at the root level, but it’s added to the subfolder’s package.json
This is almost identical to my setup 😄
@thdxr noooiiiice 😄
Yeah I like yarn workspaces too. I'm using them too. I guess I'm asking because I found more value in them prior to SST (using serverless), but I've sinced decided to stop using them within the SST project because it felt like a simplification.
Dunno if I'm making the right choice
Working fine for me now just curious
well, what’s the alternative? you could just install all packages at the project root and not use workspaces. I dunno if there’s any drawback to that, though
hmm. one thing off the top of my head: all your services would have to rely on the same version of a package. with workspaces, you could pin a package at a specific version for service1, but let service2's dependency keep updating
Yeah it makes sense that we have examples on the different setups. Then later we can write a chapter listing and comparing them.