Also interested in how the dev workflow works curr...
# help
d
Also interested in how the dev workflow works currently. At first, I thought things would run 100% local, but it appears that SST is deploying a stack before debugging/logging can work…. Next, I would have expected only a single stack, but we can see two?
Copy code
[stage]-[app]-[stack]
[stage]-[app]-debug-stack
t
Yeah the debug stack we need to create one per app. It basically contains a websocket server, s3 bucket and dynamo table. This is what your local machine will connect to to receive function invocation payloads + respond to them
d
ah… nice. I guess this is something similar to what SLS Pro hosts for you on their own infra so they can offer their local logging.
a
There is no 100% local, please check the guide in SST website.
That would be an anti-pattern for SST.
d
@Adrián Mouly yup… figured that out. Remember SST docs talking about all those local offline plugins etc. Not sure why I still thought that. We’re pretty impressed with the speed already during debugging… so great work.
a
Yeah.
This is totally different to SLS approach using sls-local and localstack.
I like this all-cloud approach.
And the WS bridge is amazing, I love the idea, totally game changer.
d
yup… I see that. Agreed. Not sure who would need to code without an internet connection anyway. So it really boils down to how fast you can make the workflow.
a
Yeah if you don’t have internet connection you can’t do much… you can’t use stackOverlow neither 😂 .
No internet = no coding.
d
right, so not quite sure why 100% local still seems to garner attention/desire.
a
Been using SLS for like 4 years and never could make it work fully local. Always found limitations.
Yeah, I don’t think too much people is looking for 100% local, I hope not.
d
ditto… and NEVER tried to use local other than invoke-local (which is just cloud)
I find that people that are more aligned to serverless as a methodology, are more understanding that an internet connection is needed. However, I have heard oldskewl server admins and even container aficionados claim that missing 100% local is serverless’ weakest part.
t
100% local is the classic situation where you try to optimize for a situation that you're in 1/100th of the time. It definitely sucks to be on a plane and not be able to have the environment but I always find different kind of work to do there
d
I must admit, there was a time, (dockercon) where I thought it amazing to be able to have an entire infrastructure app with multiple dbs, webservers, indexers etc all running locally on my laptop in k8. But that quickly died when laptop resources limited running very complex structures.
a
I have other project running on k8s, and it’s almost impossible to run the infrastructure locally.
There are too many NestJS apps in containers that has to be turned on to do 100% local development.
So we ended up using the VPN and some services are consumed from DEV cluster.
t
I was a heavy k8s user for years. I don't have much to say about it 😄
a
So it’s imposible to run this locally with your own k8s.
@thdxr my main job uses k8s, and my secondary job uses SLS/SST…. I enjoy serverless architecture a lot more.
In my k8s job we have a devops team who does “infrastructure as screenshot”…. and my serverless job is me building “infrastructure as code” :)
j
@Dan Van Brunt Here’s a little bit more about the debug stack https://docs.serverless-stack.com/live-lambda-development#sst-start. The big thing for us when we were designing it was that, it should be completely serverless, and pay per use.
a
@Jay thanks for inventing this.
j
🙏 I’m glad it’s been working well!