Shifting Gears: A Journey from Serverless Framework to SST
As a software engineer with a background in TypeScript and AWS, I’ve been immersed in the serverless ecosystem for several years. Initially, my go-to tool was the Serverless Framework, which I’ve used extensively in professional projects for over two years. However, as the landscape evolves, new players emerge, and I recently decided to explore the Serverless Stack Toolkit (SST) for my freelance work. This article will share my experiences and insights as I transition from the familiar Serverless Framework to the more opinionated and TypeScript-centric SST.
The Serverless Framework: Tried and Trusted
For most of my career, the Serverless Framework has been my trusted companion. Its flexibility, extensive community support, and multi-cloud capabilities have proven invaluable in tackling diverse projects with varying requirements. The framework’s mature codebase and regular updates instilled confidence, allowing me to deliver robust serverless solutions to clients.
However, as my projects became more complex and heavily reliant on TypeScript and AWS services, I encountered some challenges with the Serverless Framework. Configuring TypeScript support required additional tooling and boilerplate, which sometimes felt cumbersome and detracted from the development experience. Additionally, while the framework’s flexibility is a strength, it often left me wishing for more opinionated guidance on best practices and architectural patterns specific to AWS serverless applications.
I implemented a basic CRUD app in both frameworks to showcase the difference in configuration.
const serverlessConfiguration: AWS = {
service: 'serverless-crud',
frameworkVersion: '3',
custom: {
esbuild: {
bundle: true,
minify: false,
sourcemap: true,
exclude: ['aws-sdk'],
target: 'node20',
define: { 'require.resolve': undefined },
platform: 'node',
concurrency: 10,
},
},
plugins: ['serverless-esbuild', 'serverless-offline'],
provider: {
name: 'aws',
runtime: 'nodejs20.x',
region: 'eu-west-1',
apiGateway: {
minimumCompressionSize: 1024,
shouldStartNameWithService: true,
},
environment: {
AWS_NODEJS_CONNECTION_REUSE_ENABLED: '1',
NODE_OPTIONS: '--enable-source-maps --stack-trace-limit=1000',
myTable: '${self:custom.myTable}',
},
},
functions: { createItem, readItem, updateItem },
package: { individually: true },
};Serverless Framework’s flexibility results in a lot of extra configuration in required in the serverless.ts file.
Embracing SST: A Tailored Experience for TypeScript and AWS
Enter the Serverless Stack Toolkit (SST), a relatively new player in the serverless ecosystem developed by the team behind the Serverless Framework. From the moment I started exploring SST, it became evident that this tool was designed with TypeScript and AWS in mind, promising a more streamlined and tailored experience for developers like myself.
// stacks/ApiStack.ts
export function ApiStack({ app, stack }: StackContext) {
const api = new Api(stack, "Api", {
routes: {
"GET /items/{id}": "src/lambda.handler",
"POST /items": "src/lambda.handler",
"PUT /items/{id}": "src/lambda.handler",
"DELETE /items/{id}": "src/lambda.handler",
},
defaultAuthorizationType: "AWS_IAM",
});
return {
apiEndpoint: api.url,
};
}
// sst.config.ts
export default {
config(_input) {
return {
name: "sst-api-ts",
region: "eu-west-1",
};
},
stacks(app) {
app.stack(ApiStack);
}
} satisfies SSTConfig;SST configuration is more human-readable and mimics the creation of objects rather than looking like a YAML file adopted for TypeScript.
One of the standout features of SST is its native TypeScript support, which seamlessly integrates with my development workflow. No more juggling additional configurations or tooling — SST takes care of it all out of the box, ensuring a delightful coding experience with type safety and autocompletion from start to finish. But SST’s appeal goes beyond its TypeScript preference. The pre-built constructs, architectural guidance, and adherence to best practices have proven invaluable in accelerating development cycles and delivering high-quality solutions to clients.
The Live Lambda Dev feature, which allows for local development and testing with automatic reloading, has been a game-changer. The ability to rapidly iterate and test locally has significantly boosted my productivity and confidence in the code I deliver.
Navigating the Transition: Challenges and Lessons Learned
While the transition from the Serverless Framework to SST has been largely positive, it hasn’t been without its challenges. One of the initial hurdles I encountered was the limited community support and ecosystem compared to the more established Serverless Framework. However, as SST continues to gain traction, I’ve noticed a growing number of resources, examples, and community discussions emerging, mitigating this concern.
Additionally, as SST is currently limited to AWS, projects requiring multi-cloud support or integration with other cloud providers may still necessitate the use of the Serverless Framework or alternative tools. However, for my freelance work focused primarily on AWS serverless applications, SST has proven to be an excellent fit. Another aspect I had to adjust to was the opinionated nature of SST. While its architectural guidance and best practices are valuable, there were instances where I needed to deviate from the prescribed patterns to accommodate specific client requirements. In such cases, I had to be creative and explore the boundaries of SST’s flexibility, sometimes resorting to lower-level AWS constructs or custom resources.
Conclusion: Embracing Change and Delivering Value
As a freelancer, adapting to new tools and technologies is essential for staying relevant and providing value to clients. My journey from the Serverless Framework to SST has been a testament to this principle. While the Serverless Framework will always hold a special place in my toolkit, SST’s tailored experience for TypeScript and AWS serverless development has proven to be a game-changer, particularly for my freelance work.
The seamless TypeScript integration, opinionated architectural guidance, and features like Live Lambda Dev have significantly streamlined my development workflows, allowing me to deliver high-quality solutions to clients more efficiently. However, it’s important to acknowledge that no tool is a one-size-fits-all solution, and the decision between SST and the Serverless Framework (or alternative tools) should be driven by the specific project requirements, skill set, and client priorities.
As I continue to explore and leverage SST in my freelance projects, I remain committed to continuous learning and adaptation. The serverless ecosystem is rapidly evolving, and embracing change is crucial for staying ahead of the curve and providing exceptional value to clients. Whether it’s SST, the Serverless Framework, or the next groundbreaking tool that emerges, I am excited to navigate this ever-changing landscape and deliver innovative solutions that exceed expectations.
