448 karma · joined October 11, 2008
Making it easy for startups to use serverless.
Comments and feedback welcome, jay@sst.dev
Workspace support is being worked on, it was half-implemented before, so we are taking a proper pass at it now.
For switching between sessions, can you tell me about your workflow from before? Because a tab can hold a session from any project. Are you saying that opening up a tab is too heavy of an action?
GitHub issues though has been a problem from us, we deal with a ton of noise/spam.
Some background, with SST we connect your local environment to the services deployed to AWS and just run the Lambda functions locally: https://docs.sst.dev/live-lambda-development
It covers a small subset of AWS services but it is very comprehensive in what it covers.
That said though, we often work with teams in our Slack to get their setup working well. If you haven't, I'd recommend popping in and posting about it. Or just send me an email: jay@serverless-stack.com and we'll figure it out.
It's based on CDK and has a great local development environment for Lambda. It allows you to set breakpoints and test it locally: https://serverless-stack.com/examples/how-to-debug-lambda-fu...
Good luck!
It's pretty much to run it on serverless infrastructure as opposed to on containers. And to take advantage of Lambda@Edge.
It runs on your AWS account and it comes with a local development environment (https://docs.serverless-stack.com/live-lambda-development) as well.
In this example, we show how to set breakpoints through VS Code and inspect a Lambda function. Let me know if you have any questions about how this works.
We had to change the build process of Lambdas to support deploying a mock version of the function. And we need to add a new command that deployed the debug stack.
Here's how it works internally — https://docs.serverless-stack.com/live-lambda-development
Your existing CDK app should work with SST. The main difference is that SST deploys per stage (or environment). This allows you to do `sst start` that goes to one environment and `sst deploy --stage prod` that goes to another.
The work Evan does is seriously impressive.
I can see where you are coming from. What we are doing with SST does seem very complicated just to get a good local development setup.
LocalStack is a good initiative but in practice it ends up being slow. As a result, we see people using it for writing tests instead of local development.
- The Live Lambda Development environment that I talked about in the post. That's really the biggest difference. - And instead of CloudFormation YAML, SST uses CDK. So you can use regular programming languages to define your infrastructure.
For example, if your Lambda function publishes to a SNS topic that invokes another Lambda function. You can only test this locally my mocking the inputs for the first one, testing that. And repeating it for the second one.
With SST, it deploys this stack to AWS. So when you trigger this workflow, both the Lambda functions get invoked on your local machine. You don't need to mock anything. It is as if they were invoked live.