Launch HN: SST (YC W21) – A live development environment for AWS Lambda

Hi HN, we are Jay and Frank and we are working on SST (https://github.com/serverless-stack/serverless-stack https://github.com/serverless-stack/serverless-stack). SST is a framework for building serverless apps on AWS. It includes a local development environment that allows you to make changes and test your Lambda functions live. It does this by opening a WebSocket connection to your AWS account, streaming any Lambda function invocations, running them locally, and passing back the results. This allows you to work on your functions, without mocking any AWS resources, or having to redeploy them every time, to test your changes. Here's a 30s video of it in action — https://www.youtube.com/watch?v=hnTSTm5n11g https://www.youtube.com/watch?v=hnTSTm5n11g For some background, serverless is an execution model where you send a cloud provider (AWS in this case), a piece of code (called a Lambda function). The cloud provider is responsible for executing it and scaling it to respond to the traffic. While you are billed for the exact number of milliseconds of execution. Back in 2016, we were really excited to discover serverless and the idea that you could just focus on your code. So we wrote a guide to show people how to build full-stack serverless applications — https://serverless-stack.com/#guide https://serverless-stack.com/#guide. But we noticed that most of our readers had a really hard time testing and debugging their Lambda functions. There are two main approaches to local Lambda development: 1) Locally mock all the services that your Lambda function uses. For example, if your Lambda functions are invoked by an API endpoint, you'll run a local server mocking the API endpoint that invokes the local version of your Lambda function. This idea can be extended to services like SQS (queues), SNS (message bus), etc. However, if your Lambda functions are invoked as a part of a workflow that involves multiple services, you quickly end up going down the path of having to mock a large number of these services. Effectively running a mocked local version of AWS. There are services that use this approach (like LocalStack), but in practice they end up being slow and incomplete. 2) Redeploy your changes to test them. This is where we, and most of our readers eventually end up. You'll make a change to a Lambda function, deploy that specific function, trigger your workflow, and wait for CloudWatch logs to see your debug messages. Deploying a Lambda function can take 5-10s and it can take another couple of seconds for the logs to show up. This process is really slow and it also requires you to keep track of the functions that've been affected by your changes. We talked to a bunch of people in the community about their local development setup and most of them were not happy with what they had. One of the teams we spoke to mentioned that they had toyed with the idea of using something like ngrok (or tunneling) to proxy the Lambda function invocations to their local machine. And that got us thinking about how we could build that idea into a development environment that automatically did that for you. So we created SST. The `sst start` command deploys a small _debug_ stack (a WebSocket API and DynamoDB table) to your AWS account. It then deploys your serverless app and replaces the Lambda functions in it, with a _stub_ Lambda function. Finally, it fires up a local WebSocket client and connects to the _debug_ stack. Now, when a Lambda function in your app is invoked, it'll call the WebSocket API, which then streams the request to your local WebSocket client. That'll run the local version of the Lambda function, send the result back through the WebSocket API, and the _stub_ Lambda function will respond with the results. This approach has a few advantages. You can make changes to your Lambda functions and test them live. It supports all the Lambda function triggers without having to mock anything. Debug logs are printed right away to your local console. There are also no third-party services involved. And since the _debug_ stack uses a serverless WebSocket API and an on-demand DynamoDB table, it's inexpensive, and you are not charged when it's not in use. SST is built on top of AWS CDK; it allows you to use standard programming languages to define your AWS infrastructure. We currently support JavaScript and TypeScript. And we'll be adding support for other languages soon. You can read more about SST over on our docs (https://docs.serverless-stack.com https://docs.serverless-stack.com), and have a look at our public roadmap to see where the project is headed (https://github.com/serverless-stack/serverless-stack/milestones?direction=asc&sort=due_date&state=open https://github.com/serverless-stack/serverless-stack/milesto...). Thank you for reading about us. We'd love for you to give it a try and tell us what you think!