Hey all, I'm new to SST, looks awesome! We're thin...
# sst
r
Hey all, I'm new to SST, looks awesome! We're thinking of using it on our next project as we want to use CDK but it feels like quite a leap from the comfort zone that is Serverless Framework 😉 Also the local debugging feature looks amazing! I guess my only concerns are it's not yet "production ready" (though I imagine will probably be fine!) and good ol'vendor lock-in. Obviously it's built on CDK but I'm wondering - is it possible to "eject" from SST (i.e. revert to pure CDK somehow) if SST turns out to not be a fit for us down the line or if (in the unlikely event) SST was disbanded?
t
This is very explicitly one of our goals + the reason I chose SST when I was first doing my research. There are some SST specific features like live lambda debugging that you'd give up but at the end of the day you're just building on CDK and graduating out of SST is possible
SST is only additive on top of CDK so you will always be able to use anything CDK has natively
d
This is interesting... To the SST guys, what is your point where you would feel comfy going "production-ready" (v1)? I am already using you in production, but worth asking.
t
I think as a team we're looking to round out the entire offering before we can call it a v1, that's more so we can present a cohesive story around development -> production. We need to make sure we have answers for things like monitoring and inspecting logs From a stability standpoint I feel pretty good about where things are after the last 0.54 refactor. That is probably the biggest set of code changes I can see in the foreseeable future, everything from here on out should be incremental. There also a few API changes we might want to make around some of our constructs but should also be incremental Oddly enough our "stability" is less around prod and more around local development. We're built on top of CDK so we can't break too much in prod that isn't already broken in CDK. We're much more likely to break local development because that's where most of our custom code is
d
Agreed, perhaps "production" isnt the right word, but losing local development could be pretty crippling. Thanks for the clarification.
m
AWS is pretty weaksauce when it comes to local development
t
AWS generally more focused on platform capabilities than day to day experience, which is where our opportunity is
m
like I use AppSync but there’s no plan to even let the community support local development - https://github.com/aws/aws-sam-cli/pull/2491