While Serverless Framework and SAM have been around for a while and are quite popular, the local development experience for them isn't great. And they require you to define your resources using the really verbose CloudFormation YAML (or JSON).
In comparison, SST features:
- A Live Lambda Development environment, that introduces a completely new local development experience for serverless.
- And it uses AWS CDK, allowing you to define your resources using regular programming languages.
We think these two details, drastically sets SST apart from the rest of the options out there.
Yes. The only caveats are:
sst.Appis included by default and is used in place of
sst.Stackis necessary for SST to be able to deploy to multiple stages and is used in place of
sst.Functionis necessary for the Live Lambda Development environment. But if you don't need that you can use the CDK function constructs.
No, you don't have to use them. But they can be really handy when building out your serverless app. For example, the
sst.Api construct gives you a really nice interface for defining your routes and giving them permissions.
SST is still under active development. And we are constantly fixing bugs and supporting new use cases and setups.
That said, we see SST being used in production by quite a few of our users over on Seed.
So feel free to give it a try and let us know if you run into any issues.
SST is relatively new but the team behind it has been working on serverless related projects for the past few years. The Serverless Stack Guide has been around since 2017. Seed has been generating revenue since 2018. We are also backed by some of the most prominent investors in Silicon Valley.
So checkout our public roadmap to see where SST is headed.
SST has a couple of defaults, like a built-in linter, type checker, and bundler. It also has a list of higher-level constructs.
You can disable the linter, provide your own TypeScript config, and disable bundling. You also don't have to use the higher-level constructs that SST has and just use the native CDK ones.
If you hit a limitation, feel free to hop into our Slack community and let us know about it.
CDK has a construct for building Lambda functions, @aws-cdk/aws-lambda-nodejs. But SST does not use it. Here's why.
SST's Live Lambda Development environment allows you to test your Lambda functions live. To do this, it watches your file changes and transpiles your functions. While they are being transpiled, it blocks any requests that are made to them. To ensure a great experience, it needs to do this process as fast as possible. So we decided to use esbuild, since it's fastest option. We also maintain an esbuild service internally and call it programmatically to make rebuilds as fast as possible.
It also makes sense to build the Lambda functions in a similar way while running
In addition, we also decided to use esbuild to transpile your CDK code, so you can use the same flavor of JS as your Lambda functions.
SST internally includes CDK, so you don't have to. We update this version fairly frequently. But if you need the latest version right away, open an issue and we'll push out an update.
Originally when SST was released, it was meant to be a way to use CDK alongside your Serverless Framework apps. While you can still do that. SST's Live Lambda Development makes it a first-class dev environment for serverless apps.
So you don't have to use Serverless Framework together with SST.