Introducing SST: The Tool Making Full Stack Web Application Development Fun with AWS

Amazon Web Services (AWS) is a powerful and comprehensive platform for cloud computing and web services. However, for web developers, the sheer volume of individual services and their integration can be overwhelming and complex. This is where Serverless Stack (SST) comes in. SST is an open source tool that simplifies the process of building full stack web applications with AWS, making it not only easier, but also fun.

The Problem with AWS

One of the biggest challenges with AWS is the multitude of individual web services it offers. From S3 storage buckets to Lambda functions, API Gateway, RDS, DynamoDB, Cognito user authentication, and more, the list goes on and on. Integrating these services and putting them all together in a unified package can be extremely complicated and time-consuming, especially for developers who are not familiar with the AWS console or infrastructure.

SST: The Solution

Serverless Stack (SST) addresses this problem by representing back-end infrastructure as code with TypeScript. This means that developers can integrate various AWS features without ever having to touch the AWS console. SST also comes with built-in deployment support for frameworks like Next.js, Astro, and Spell Kit, making the entire process seamless and efficient.

Once initialized, SST provides a variety of simple constructs that represent infrastructure declaratively. Under the hood, this code is based on Amazon’s Cloud Development Kit and CloudFormation. These constructs are grouped together in “Stacks,” which can be deployed together or run locally with the `sst dev` command. This provides a local development environment with live reloading and a web-based console to manage Stacks, minus the typical pain points associated with AWS development.

Getting Started with SST

To get started with SST, you’ll need the AWS CLI with credentials set up locally. Next, run the `npx create-sst` command to deploy SST to your favorite framework or initialize it as a standalone project. This will scaffold a mono repo, with the `packages` directory containing the code to power the back end. Inside this directory, you can write serverless functions in TypeScript that are powered by AWS Lambda and use API Gateway as the front door.

Running the `sst dev` command will automatically deploy the required resources to the cloud and provide a local development environment. Any changes made to the code will be immediately reflected in the cloud. The local SST console allows you to view logs and manage Stacks seamlessly.

Enhancing Your Application with SST

With SST, you can expand your application by adding additional features. For example, you can add an event bus to trigger Lambda functions based on different events, enable file uploads by adding the bucket construct, add a Postgres database with RDS, and enable user authentication with the auth construct. Additionally, you can define cron jobs that run on a schedule and point to specific Lambda functions. When the stack is complete, you can add it to the SST config file and deploy it to the cloud with a single command.

Conclusion

In summary, SST is a powerful and user-friendly tool that makes building full stack web applications with AWS a fun and seamless process. By representing back-end infrastructure as code in TypeScript, SST simplifies the integration of various AWS services, provides a local development environment with live reloading, and offers a web-based console to manage Stacks efficiently. For web developers looking to harness the full potential of AWS without the complexity, SST is truly a game-changer.

36 COMMENTS

  3. While this is interesting, I'm always wary of these layers-upon-layers of magical abstractions. All cost concerns aside, which can easily be controlled and aren't the boogyman man of the comments might suggest; you're not learning enough about the underlying infrastructure you're maniuplating. All abstractions come with this cost. Even with CDK, which I've adopted and started using because you need some sort of IaC tool for automation, you've got to understand what's happening under your code. To me, if you're strictly AWS, CDK is the way to go, and adding another layer on top of that might be easier, but you learn and understand less of the consequences of what you're executing.

    All that being said, we're mired in frameworks, built atop frameworks, embedded with endless layers of abstraction and configuration. There's a shiny new toy every-other-day. You can chase your tail around for years and never settle on "THE stack"…and all of these toys achieve the same thing, in the end. At what point do you select "the best" tools and stick to them for more than a few months, or even a few years?

    As neat as this is, I prefer to stay as close to the "bare metal" as possible, while accepting that the market will push you into certain things that you have no choice in adopting. Keep it as simple as possible, even if it's more difficult and requires a little more code and understanding. These frameworks come and go, seemingly overnight. If you stick to strong fundamentals and as few abstractions as possible, you'll waste less time and build more stable environments.

  9. SST is cool but only for those who know the underlying AWS services it spins up and working with them at least for few months. If a newbie uses SST, he's screwed.

  22. Wow, if this works, it looks pretty cool and may actually improve the dev lifecycle…. as long as your not hitting bugs that are impossible to discern with everything 'under the covers'.

LEAVE A REPLY

Please enter your comment!
Please enter your name here