I have a similar setup to the demo-ext example (se...
# guide
s
I have a similar setup to the demo-ext example (separate repos for API and infrastructure). I've converted my infrastructure repo to SST, and it works great! i'd like to try converting a portion of my API to use SST, so I'm brainstorming how I want to resolve the cross stack resources.
f
Yeah, given SST now supports Lambda/Api development, I’d recommend merging resources and api into the same sst app.
The guide is a bit out dated, and we will soon update it with this setup.
So, the repo structure looks like:
Copy code
/
  lib/
    index.js
    ApiStack.js
    CronJobStack.js
    ResourcesStack.js
  src/
  package.json
  sst.json
So, all the CDK code goes into
lib/
and lambda code goes into
src/
s
That makes a lot of sense, and was the path I was heading down. Thanks for the confirmation
p
@Frank I believe it comes from the origins of SST project, being mainly infrastructure, but I'd consider changing these folder names a bit because it's a bit misleading I'd say. Like `lib`is a very generic name to indicate that your infrastructure must live there. Are you guys already considering something in this direction? It's only a suggestion, btw...
f
@Paulo Yeah, I can see that. I know
lib
is the standard directory in CDK. @Jay what do you think? Paulo and a few others have brought this up before. Might be more intuitive to name the directory
stacks
or
resources
?
s
Totally second @Paulo. the very least making it configurable, maybe on
sst.json
.
p
Hey @Frank. As you know naming is the hardest part of software development 🙂 and very subjective. To me, it would make sense to call the main folders
infrastructure
and
api
, but not all lambdas are API so perhaps something broader like
functions
or
application
. Btw, between `stacks`and
resources
I'd go for
stacks
which sounds less generic.
f
@Sione @Paulo Thanks guys! Let me talk to the team about this. I opened an issue for reference https://github.com/serverless-stack/serverless-stack/issues/150
j
Yeah this makes sense. We should change it, or at least add an option.