https://serverless-stack.com/ logo
Join Slack
Powered by
also what do you normally name your main stack tha...
# general
m
also what do you normally name your main stack that holds the app resources? like if my app is named Foo and I make a Stack called Foo to hold everything then everything gets prefixed with dev-foo-foo- which is silly.. what’s the best practice here?
t
I have extremely granular stacks so they end up being named things like API or Database
m
Do you recommend splitting things out into multiple stacks or sticking with a single stack until you reach the limits
m
@thdxr so you have one app with tons of stacks inside of it?
@Michael Wolfenden CDK best practices says you should consider having one “stateful” stack that you mess with as little as possible that holds stuff like S3, DB, etc. since modifying those can trigger destroying the data. nested stacks are nice but slow deploys down and aren’t yet compatible with lambda hotswap
t
I used to try and minimize number of stacks but I found that it increased the number of cross stack deps and generally slowed stuff down more
So now I go for granular stacks, the functional stack pattern I shared last month makes it a lot more manageable
I find that cdk best practice odd. For me I prefer to keep things seperate so if I touch one thing and screw something up it minimizes damage
m
maybe the idea is you add some extra protection to the stateful stack
https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html see the section “Separate your application into multiple stacks as dictated by deployment requirements”
if you disagree with it you we should discuss on the CDK slack!
t
Just read it, not sure if I explicitly disagree but I think there's some quirks. The default retention behavior on stateful resources is already set to retain so I'm generally not worried about accidentally destroying anything. That said, because I'm breaking things up a lot I'm already isolating those in a stack anyway
And then once retained, importing it back in is such a huge pain in the ass. I've actually never been able to do it
If cfn was faster I wouldn't mind having fatter stacks but it really starts to slow down when there's a lot of resources
I do feel a bit like the CDK team doesn't actually use CDK since they just work on it. There's some imo weird suggestions in this doc
Create a stack for your production environment, and a separate one for each of your other stages, and put the configuration values for each right there in the code
m
lol yeah
i think you can say that about most AWS services and libraries tbh
i often ask myself “I wonder if anyone at amazon has used this beyond a trivial case”
t
It makes sense, even we struggle to find time to both work on SST and use SST when there's a lot to do. But ultimately I always have a side thing I'm tinkering on where all the best ideas come from
s
Love your pragmatism @thdxr
m
thdxr how do you share lambda defaults across your different stacks? where do you set them?
I just hit >500 resources so I'm going to go for your approach..
also do you use nested stacks?
I have to split my graphql resolver functions into different stacks because I have too many now, exceeding the 500 resource limit. wondering how to share default lambda env vars and permissions across all of them
I tried making separate stacks and now I have the problem of doing something like 
s3Bucket.grantPut(myLambda)
causes a circular dependency error. didn't have this before when I had one stack with a few nested stacks inside. how did you solve this?
t
For defaults we provide an app.setFunctionDefaults
I don't use nested stacks (never really saw the point of them but maybe it'll click one day)
The circular dependency error I don't remember exactly how I resolve it - think I typically use sst's permission concept which gets around it
Cc @Frank
m
ok i switched everything to stacks. seems to have made the circular dep issue go away. i'm going to have to figure out how to migrate my DB, S3, and cognito though 😕
currently what it looks like
t
Moving stateful reasons is extremely difficult, I've never been able to actually pull it off but I know it's theoretically possible
m
yeah it's going to be a painful refactor
i'm just going to dump s3 and postgres
cognito idk what to do about
t
If you need a live migration for pg, AWS DMS actually works well
m
yeah i can do it offline thankfully. DMS kinda blows for aurora serverless tbh (idk why lol)
t
I've migrated users in cognito also but only possible if you're using password less. Otherwise you have to lazy migrate them as they're logging in
m
i'm using openid connect
f
s3Bucket.grantPut(myLambda)
causes a circular dependency error
There are technically 2 ways to grant permissions: 1. Add 
s3::xxxx
permission for resource 
s3Bucket.bucketArn
to 
myLambda
role’s policy. This way 
myLambda
depends on 
s3Bucket
. 2. Create a new IAM policy in `s3Bucket`’s stack with 
roleArn
set to `myLambda`’s role. This way 
s3Bucket
depends on 
myLambda
. I don’t recall on top of my head which way does 
s3Bucket.grantPut
do. But if it causes circular dependency error, you can try the other approach.
m
getting rid of nested stacks and making everything a stack seemed to fix it, thanks
big refactor.. have to replace all my stateful stuff. oog
i'm getting closer to the "graphql-stack" style you have thdxr though not using your wacky resolver setup
turns out the disadvantage to making lots of smaller stacks is that if you delete something in the wrong order then you get stuck in a hell where nothing can be updated or deleted because it refers to some resource in another stack that doesn't exist anymore and you're completely fucked. just FYI
this screws me over big time
I'm in a state where I can't delete anything, even if I retain resources. i'm using SST 0.66. I read https://docs.serverless-stack.com/advanced/cross-stack-references and am desperately trying 
exportValue()
but I'm not really clear on how to fix my situation
f
leaving a link here for ppl who run into the same issue, you can continue the conversation here https://serverless-stack.slack.com/archives/C01JG3B20RY/p1646912974413509
3 Views
Open in Slack
PreviousNext
Powered by