Work on your Lambda functions live

AWS CDK has been great for us and our readers over on Serverless Stack. But the local development experience for Lambda isn't great. To fix this we created a Live Lambda Development environment in SST. SST makes it easier to build serverless apps by allowing you to work on your Lambda functions locally while connecting to your deployed resources.

Before we look at how it works, let's look at what the local development environment for serverless is usually like.

Background

Working on Lambda functions locally can be painful. You have to either:

1. Locally mock all the services that your Lambda function uses

   Like API Gateway, SNS, SQS, etc. This is hard to do. If you are using a tool that mocks a specific service (like API Gateway), you won't be able to test a Lambda that's invoked by a different service (like SNS). On the other hand a service like LocalStack, that tries to mock a whole suite of services, is slow and the mocked services can be out of date.

2. Or, you'll need to deploy your changes to test them

   Each deployment can take at least a minute. And repeatedly deploying to test a change really slows down the feedback loop.

Introducing sst start

To fix this we added the sst start command to the Serverless Stack Toolkit (SST). It's an extension to AWS CDK that makes it easier to build serverless apps using CDK.

This command does a couple of things:

1. It deploys a debug stack with a WebSocket API to the same AWS account and region as your app.
2. It deploys your app and replaces the Lambda functions with a stub Lambda.
3. Starts up a local WebSocket client to connect to the debug stack.

The debug stack contains a serverless WebSocket API and a DynamoDB table. The stub Lambda when invoked, sends a message to the WebSocket API, which in turn sends a message to the local client connected to it. The client then executes the local version of the Lambda function and sends back the results to the WebSocket API. Which then responds to the stub Lambda. And finally the stub Lambda responds back with the results.

An Example

Let's look at an example.

In this sample app we have:

1. An API Gateway endpoint
2. An SNS topic
3. A Lambda function (api.js) that responds to the API and sends a message to the SNS topic
4. A Lambda function (sns.js) that subscribes to the SNS topic

So when a request is made to the API endpoint, the stub version of api.js gets invoked and sends a message to the debug stack. This in turn gets streamed to the client. The client invokes the local version of api.js and returns the results to the debug stack. The local version also sends a message to the SNS topic. Meanwhile, the stub api.js responds to the API request with the results. Now the stub version of sns.js gets invoked as it is subscribed to the SNS topic. This gets sent to the debug stack which in turn gets streamed to the client to execute the local version of sns.js. The results of this are streamed back to stub sns.js that responds with the results.

You can try out this sample repo here.

Advantages

This approach has a couple of advantages.

• You can work on your Lambda functions locally
• While interacting with your entire deployed AWS infrastructure
• It supports all Lambda triggers, so there's no need to mock API Gateway, SQS, SNS, etc.
• It supports real Lambda environment variables
• And Lambda IAM permissions, so if a Lambda fails on AWS due to the lack of IAM permissions, it would fail locally as well.
• And it's fast! There's nothing to deploy when you make a change!

A couple of things to note.

• The debug stack is completely serverless
  • So you don't get charged when it's not in use
  • And it's very cheap per request, it'll be within the free tier limits
• All the data stays between your local machine and your AWS account
  • There are no 3rd party services that are used
  • Support for connecting to AWS resources inside VPC is coming soon

Conclusion

The sst start command in SST creates a live lambda development environment. By extending AWS CDK, it allows you to build serverless applications in CDK while having a first-class local development environment.

As one of our early users put it; sst start is the future of Lambda development

If you like the SST project, consider starring our repo —

serverless-stack / serverless-stack

Serverless Stack Toolkit allows you to build serverless apps using CDK.

Serverless Stack Toolkit (SST)

---

Serverless Stack Toolkit (SST) is an extension of AWS CDK that:

• Includes a Live Lambda Development environment
• With zero-config support for ES and TypeScript using esbuild
• Allows you to use CDK with Serverless Framework

SST also supports deploying your CloudFormation stacks asynchronously. Seed natively supports concurrent asynchronous deployments for your SST apps. And SST deployments on Seed are free!

SST also comes with a few other niceties:

• Automatically lints your code using ESLint
• Runs your unit tests using Jest

Behind the scenes, SST uses a lightweight fork of AWS CDK to programmatically invoke the various CDK commands.

Quick Start

Create your first SST app.

$ npx create-serverless-stack@latest my-sst-app
$ cd my-sst-app
$ npx sst start

Live Lambda Development

The sst start command starts up a local development environment that opens a WebSocket connection to your deployed app and proxies any Lambda requests to your local machine…

View on GitHub

Comments

[Yogeswari Narayasamy]

Would this work with golang?

[Frank Wang]

Hi @yogesnsamy , Golang is on our roadmap. Currently, only Node and Typescript are supported. We are hoping to add support for Golang in the next couple of months with some help support from the community contribution.

[Frank Wang]

Hey @yogesnsamy , Golang support has been added in v0.10.8.

Here is a REST API example in Golang - serverless-stack.com/examples/how-...

[Otto Flores 🇬🇹]

does this work with python?