just dumping this here in case it helps anyone. th...
# helps
Sam Hulick
08/08/2021, 11:46 PMjust 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
../v2-microservices
├── 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 filesSam Hulick
08/08/2021, 11:50 PMhmm. I should make a GitHub template, maybe
f
Frank
08/08/2021, 11:55 PM
@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.
d
David Martin
08/08/2021, 11:55 PMi really like how your organized your infra. my schema.graphql is currently under src, gonna copy yours.
David Martin
08/08/2021, 11:58 PMquestion - 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!
s
Sam Hulick
08/08/2021, 11:59 PMsure! 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-packageSam Hulick
08/09/2021, 12:00 AMthe actual package is installed in
node_modulest
thdxr
08/09/2021, 12:00 AMThis is almost identical to my setup 😄
s
Sam Hulick
08/09/2021, 12:00 AM@thdxr noooiiiice 😄
d
David Martin
08/09/2021, 12:08 AMYeah 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.
David Martin
08/09/2021, 12:08 AMDunno if I'm making the right choice
David Martin
08/09/2021, 12:09 AMWorking fine for me now just curious
s
Sam Hulick
08/09/2021, 12:10 AMwell, 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
Sam Hulick
08/09/2021, 12:11 AMhmm. 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
j
Jay
08/09/2021, 1:20 AM
Yeah it makes sense that we have examples on the different setups. Then later we can write a chapter listing and comparing them.