SST is a framework that can be described as a wrapper around CDK for AWS. It focuses on taking the power of CDK and adding local development magic such as live lambdas (actual AWS infrastructure in local development!), hot reloading, and recipes for bootstrapping common infrastructure patterns like auth, lambda, databases and frontends. The goal is to get AWS serverless as close to your actual environments as you can locally and to make it easy and pain-free to do this. Then to make the deployment of this application to infrastructure that would be the same in development.

Let me start by saying it's awesome, if not entirely there yet. I have had a few issues, mainly one big one with how deployments work compared to local debug deployments you would use for day-to-day development.

I eventually got it to deploy properly by updating my SST version and waiting quite a while after deployment. It seemed to need a few hits of the API before it would work properly. Weird but it’s sorted.

I don’t say any of these things to scare you, it’s a relatively new tool and with it comes a few bugs, which are things to keep in mind when choosing any tools.

Local development

Serverless as a rule is pretty annoying to run locally, even when you achieve this, it's usually in a way that mimics AWS but never truly replicates it. This is a problem for getting your local environment to work as it does on AWS infrastructure. The biggest issue you often run into is that it works locally but it doesn’t at all in AWS. SST solves this problem by running your local instance on AWS itself, just like it would if you were to deploy to prod. You might then wonder, how is the developer experience? Well, amazing! The reason it's so incredible is that SST pushes all your code to AWS and then uses a debug stack (additional lambdas and AWS infrastructure) to proxy all your hosted code right to your local host. Furthermore, it has hot code reloading allowing you to make changes to your code and have it deployed instantly live. It even tracks any infrastructure changes and lets you know when you need to redeploy, only changing the difference between the two. Note the first time it will take around 15 minutes to deploy your local stack, however, once you have deployed the time for any code changes to be made is in the order of 100ms, almost instant.

SST console

SST includes a console that you can use to hook into the logs across the stack, look at your database tables and your auth pools. It truly makes your local development life easy. You can use it to run HTTP calls, check that data has actually entered your Dynamo table, or see that an event was indeed put into your Event Bus as you expected.

These are all the major tabs in the console, pretty impressive.

Running your stacks

Above is all you need to get your system up and running on real AWS infrastructure.

sst start is where the real magic happens. This is what creates your local environment and attaches all the debugging infrastructure to make hot reloading and local host proxying work. There is talk about future versions of SST where it’s no longer required to deploy a debug stack which would make local development even quicker and even closer to production.

sst deploy --stage=production this command is what deploys your stacks to an environment, swapping out production to Staging, gives you an entirely new stack, it's as simple as that.

sst remove no longer want your stack? Simply remove it and everything will be removed. One caveat to this is that it will not delete your database (Dynamo in my case), thus if you try to redeploy the stack again you will have to manually delete the tables otherwise the entire stack fails to deploy.

Deployments

Much like CDK, well very much like it because it’s some sugar on top. It uses Typescript to create your infrastructure as code and the. Allows you to deploy your stacks as environments, think dev, staging, and production. This makes it dead easy to deploy a new environment and be confident it will just work!

Above is the code that dictates how the Lambda functions are created. Simply it's just a function that takes in a stack which is the current instance of your infrastructure. Just below that, I am importing the database table: table and event router bus. The beauty of SST means that I can add the table and the bus to the permissions sections and it handles all the permissions required with no effort on my end.

routes is where we define the individual lambda endpoints of the system and what HTTP calls they map to.

Lastly, we return the API endpoint and the API itself to then be consumed in other infrastructures as code files, much the same as the bus and table.

One of the coolest things I found was that if you have any endpoints that you need to pass around, for example, API endpoint to be consumed by the frontend, you simply add that to your frontend environment variables like below and your frontend has it there ready to be used. Line 9 highlights the API URL for the front end. I can’t tell you how handy it is to have the environment variables easily passed around to my other services as maintaining this manually can be an absolute nightmare!

If you are familiar with CDK this all might look familiar and that is good, it's basically a higher-level abstraction of CDK. If you have never seen CDK before then it's still really easy to understand what is going on from a brief read.

Recipes/Guides

It’s very easy to get started thanks to the excellent documentation and the recipes that show you exactly how to implement something. I built my event-driven architecture repo by piecing together the guides on the various AWS services. I still needed to tinker with a few things to get it right but for the most part, 80% of it was quick and the rest took some trial and error.

The creators of SST put a lot of effort into the developer experience because there is even a 1000-page ebook that runs you from start to finish building an entire full stack application. There is an extreme amount of information on how to do just about anything. One of the most interesting things that I found was that if I had an issue there might not have been a lot of stack overflow questions about it but their docs would highlight something that would help. Maybe it was a constructor option I was missing, re-reading the docs again would highlight that, or maybe down below where it would list all the passable arguments I could see what I was missing or an argument that might solve my problem.

When in doubt, they have a discord that is an excellent resource, they answer questions, post updates, and live streams, you name it and I bet you will find it there.

Going back to the end-to-end guide they have which takes you from start to finish is just such an amazing feat. I did **not** go from start to finish, but it allowed me to pick and choose bits and pieces from the guide as I needed them with a real application example. This made it incredibly easy to get my head around what was going on, especially as someone with no CDK experience.

Things to keep in mind

This tool like everything is no silver bullet. It’s lacking in some of the AWS services out of the box but you can always drop down into native CDK to achieve this which assures me that even if I did pick this tool I know I won’t be stuck if it doesn’t support something.

If you want to check out the example solution I built as a toy clone this repo and have a play. It highlights a few services glued together using SST as well as how easy it is to deploy to environments. There is also a GitHub deploy script I have, however seed.run is a service that can handle all the deployments for you as well as logs and the output of all your URLs. Furthermore, it supports SST as a first-class citizen along with the Serverless Framework.

Would I recommend this to a friend?

Absolutely, to me, this is high praise, if I'm recommending this to a friend it means I would also use it personally. I don’t think I would quite recommend it for enterprise yet, but if I was a developer working in an enterprise I would love to have it. I would highly recommend it for any situation that isn’t an enterprise. I will include that there might be bugs, you might have to ask for help on Discord or their forums and you won’t find a lot of information/questions in stack overflow, but the documentation is fantastic, and the people running the show are eager to help and the community as a whole is a great one.

Links

https://github.com/Errol-Hassall/event-driven-ticket-ordering the repo I created to learn SST and event-driven architecture

https://sst.dev/
https://seed.run/ deployments and monitoring made easy
https://sst.dev/guide.html Amazing guides on how to get up and running with a lot of SST and serverless
https://discord.gg/sst SST discord

SST Making serverless easier