An introduction to SST and Infrastructure as Code

Most likely it is not a coincidence that you are interested in Blitzship.

Probably you are a developer that has been dreaming about finally getting to know AWS. Or maybe you have worked with AWS before, but you are not sure how to structure your code to make it easy to maintain and scale.

Either way, I'm glad you are here.

To get things rolling, let's try to get a better understanding of how Blitzship is using AWS to define all our infrastructure in the easiest and most efficient way possible.

SST (Serverless Stack Framework)

To define, change and deploy all AWS infrastructure, we are using the SST (opens in a new tab) framework.

SST allows you to define your AWS infrastructure as code, making it easier to manage, version, and deploy your serverless applications.

What problem does SST solve?

A typical SaaS uses an array of different AWS services. This may include things like AWS Lambda for serverless functions, Amazon API Gateway for routing, DynamoDB as a database, S3 for file storage, etc. Now, working directly with AWS Lambda, API Gateway, and other AWS services through the AWS console can be a bit cumbersome.

Furthermore, since these services run on AWS, it can be tricky to develop, test and debug them locally.

This is exactly what SST solves. SST makes it easy to build full-stack applications by allowing you to:

• Define your entire AWS infrastructure in code
• Use infrastructure components designed specifically for modern full-stack apps
• Test your application including all infrastructure live on your local machine

And how does SST do this? Well, it's called Infrastructure as Code.

Infrastructure as Code

A lot of developers try to set up all their infrastructure manually in the AWS console. It’s much easier and more straight forward, however, to configure all that infrastructure programmatically.

You write regular TypeScript code and SST converts that code into a series of API calls to your AWS account. The code you write is a description of the infrastructure that you are trying to create as a part of your project.

This general pattern is called Infrastructure as code (IaC) and it has some massive benefits.

• It allows us to completely automate the entire infrastructure creation process.
• It’s not as error prone as doing it by hand in the AWS console.
• Describing the entire infrastructure as code allows you to create and replicate multiple environments with ease

Here is an example of how that works. Let's say we want to create a REST API to receive webhooks from Stripe.

const api = new sst.aws.ApiGatewayV2("Api");
 
api.route(
 "POST /billing/webhooks",
 "packages/functions/src/billing/webhooks.handler"
)

As you can see, we simply instantiate ApiGatewayV2 component offered by SST, set a POST route and hook it up with a handler function from our codebase. This will automatically spin up an API Gateway endpoint and a Lambda function to receive webhooks from Stripe.

Awesome, isn't it?