sst

from your AWS services - Easily manage permissions to your AWS resources - Works with any CI service, supports PR/preview deployments - Uses AWS CDK to define your infrastructure as code We wrote about how to get started and compared the various deployment options: https://serverless-stack.com/examples/how-to-create-a-nextjs-app-with-serverless.html. You can also check out the docs: https://docs.serverless-stack.com/constructs/NextjsSite We'd appreciate if you took it for a spin and gave us some feedback!

velop your Lambda functions locally while connecting to others AWS services without needing to mock them locally. Behind the scene, the lambda requests are streamed to ur local, runs ur local function, response streamed back to Lambda. So you can iterate on ur function code without redeploying. Think of your Lambda functions are Live Reloaded. You can see it in action here — https://youtu.be/hnTSTm5n11g I’m the core maintainer of the project. And folks in our community are saying using SST feels like "working in the future" ;) I'd love for you to give it a try. We are also a part of the YC W21.

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. 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), and have a look at our public roadmap to see where the project is headed (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!