Whoa. When do we get to take advantage of this? <h...
# general
s
t
Ah nice
This is terraform's default behavior since they can only go through api
Let me make an issue for this, wonder if it makes sense as a default
s
I think so. Unless
stage === 'prod'
t
We don't actually have a way to know if stage is prod (I personally name my production stage
production
)
s
Right, the stage is arbitrary. So maybe have a way for people to enable or disable that new ability, based on any given stage
t
yeah can probably start with that
Maybe default to it for
sst start
s
app.disableRollback()
for example
Oh yeah, that sounds good
f
Yeah, was reading about this. It seems we can implement this without users noticing. As in they run
sst deploy
and gets an error. Then when they run
sst deploy
again, it picks up from where it’s left one.
s
people at AWS must’ve seen @thdxr’s CloudFormation meme and felt embarrassed 😆
t
lol
s
at any rate, I’m glad they’re paying attention to people complaining about slowness!
f
i don’t understand why they are not making it faster… seriously…
t
It is kind of sad that terraform, which is implemented without any internal access to AWS, gives a better experience
s
yeah. I’ve never used it because I didn’t wanna get hooked/dependent on it since it’s third-party 🙂
f
we might look at terraform-cdk when we support other cloud.. I have a feeling that Dax is going to vouch using that for AWS as well 🤪
t
To this day I am still confused as to what terraform-cdk is
or rather, why they named it cdk and how aws is involved