Gareth McCumsksey of serverless Inc. wrote this recently and in the discussion thread underneath it's frequently stated that there are no solutions for hot reloading of lambdas and no local debug capability. I wonder if you guys wanted to chime in https://dev.to/garethmcc/why-local-development-for-serverless-is-an-anti-pattern-1d9b

Oh that’s an interesting take. I obviously don’t agree. But let me read this in detail in a sec.

This is interesting, I had this in mind for some time too.

One of my main issues right now is the Lambda Global Scope Leaks. This is not a problem in SLS offline. I wasted weeks chasing this, only to find some small notes in AWS about global scope for Lambda. Finally I have to refactor my code and I have to test this in the cloud because the issue doesn’t happen locally. So I’m already there.

100% agree that using localstack is the wrong direction

Yeah I think we need to push the boundary on what is considered “instant”. I benchmarked

sst start

last week, and I think we can shave couple hundred ms overhead off each invocation by keeping a pool of long running handler processes around (something @thdxr suggested a while back)

I started reading it - was too lazy to read the whole discussion - let's be honest - @Jay / @Frank - you guys nailed the whole thing with the sst start black magic 😄 This is how it should have worked from day one 😄 and once you work out how to spread it across other clouds with TF CDK - your appraoch will take over the world - I see no other option 😄

haha that’s awesome to hear!

moving canopy entirely to SST was a great choice for us, away from sls. and shoot man, now if i want to try another tool, i have regrets. while it's nice to have an internet-free, local server + local postgres, taking things from local to prod can be haphazard.

Thanks Dennis! It’s motivating hearing that!