When it comes to the Serverless Framework, there can be quite the learning curve. However, with a few helpful commands, you can streamline your Serverless development and keep your focus on building versus debugging.

The purpose of this article is to show a series of commands which we constantly use at Serverless Guru to speed up debugging and provide results faster to our clients.

Commands

In the following section, we will show the commands and give some brief insight into how we use them at Serverless Guru.

Packaging

When it comes to packaging your AWS Lambda functions you will be tempted to simply run the sls deploy command which will zip up your lambda file, node_modules, and any other files which you’ve told the Serverless Framework to include. However, running sls deploy also begins the deployment to AWS and if we simply want to inspect the size and the contents of the zip file we can run the following command:

$: sls package -v

Note: You can still pass flags (e.g. --stage <> or --region <> ) if you have these flags defined in your serverless.yml file.

If you are interested in achieving even smaller package sizes, we frequently use the include/exclude pattern and leverage open source Serverless Framework plugins. For an in-depth breakdown, check out our friends at Serverless Stack, they wrote an article on this topic.

Local Testing

Developing serverless applications and having any monocle of speed requires local testing your AWS Lambda logic. Which is to say, you don’t want to wait for a deployment to finish every time your variable name is missing a character.

As you first start, local testing, there is a helpful command which you can leverage.

$: sls invoke local -f [function_name] -d "{ ... }" -v

The documentation includes the “options” which is what you see above with -d. It’s important to spend time reading the available options for this command to understand what makes the most sense for your project.

We would recommend using, sls invoke local -f [] -p ./test-events/create-user.json the -p tells the command to reference a file in your project versus -d which passes a hardcoded event object. Making -p scale significantly better as you can track all your events.

As you get deeper, we would recommend leveraging alternatives to sls invoke local which would be sls-offline, a Serverless Framework plugin which helps you simulate both AWS Lambda and API Gateway locally. This will allow you to make requests to your lambda functions directly through your browser if you’re AWS Lambda functions are setup as APIs.

Deploying a single function

As your serverless applications grow in size and complexity. It will become even more paramount to not run sls deploy for every code change. As this will require a few additional steps, such as checking for changes to our infrastructure in the serverless.yml and checking every AWS Lambda function in our project for changes, which we don’t care about when simply making a small code change to a single function.

$: sls deploy function -f [function_name] -v

The documentation has a few options and even shows a way to only update the config of your lambda function (e.g. timeout, memory).

Install plugins like a Serverless master

When you are ready to start working with Serverless Framework plugins. You will need to install them by following these steps:

1. Install the plugin, npm install --save-dev <>
2. Create a plugins section in your serverless.yml

You may be asking, well if it’s only two steps, why do I need a command? Because avoiding human error, should be at the forefront, we can handle both of the steps above by doing the following:

$: sls plugin install --name [plugin-name] -v

In the documentation, you can also see that it’s possible to pass a version number to the command which would turn the above command into:

$: sls plugin install --name [plugin-name]@[version] -v

Great things are done by a series of small things brought together — Vincent Van Gogh

Debugging Serverless Framework variables

When you’re developing serverless applications a common obstacle is this feeling that you’re developing inside of a black box. Meaning there is so much abstraction happening beneath your feet, that it can make you feel helpless to small issues, such as a variable not resolving properly inside your serverless.ymlfile.

Well, luckily, there is a Serverless Framework command which helps you overcome this obstacle by printing out the serverless.yml file with all the variables resolved.

$: sls print

With the sls print command, we can see the following serverless.yml snippet go from this:

service: real-time-weather
provider:
  name: aws
  stage: ${opt:stage, "dev"}
  region: ${opt:region, "us-west-2"}
  profile: ${opt:profile, "serverlessguru"}
custom:
  base: ${self:service}-${self:provider.stage}
  dyanmoDBUsersTable: ${self:custom.base}-users-table

To this:

service: real-time-weather
provider:
  name: aws
  stage: dev
  region: us-west-2
  profile: serverlessguru
custom:
  base: real-time-weather-dev
  dyanmoDBUsersTable: real-time-weather-dev-users-table

And just like that, we are able to easily find out that, our variable dynamoDBUsersTable has the stage appended to the name which in this hypothetical scenario was our issue.