For those that aren’t aware, the Serverless Framework is a great way to simplify building serverless apps with AWS Lambda or Azure Functions.

Serverless computing is a very large break from the traditional way we developed software and deployed software to servers. Serverless computing is basically an architecture where code is stored and executed by a fully managed provider. The development and operations team don’t manage the servers that the code functions on which can help companies save an incredible amount of time and better focus on their products.

My blog post What is Serverless explains serverless and how it functions in a lot more detail.

Why develop locally?

If your organization is using AWS Lambda and the serverless framework, it becomes fairly easily to develop locally before deploying to the server.

Developing locally makes a lot more sense than deploying to a dev environment consistently because it helps save time, save some cloud costs, and avoids obvious embarrassment. 🙂

When I develop locally I can make changes in seconds instead of having to wait a minute or so every time I redeploy changes. With AWS, there’s times you can’t easily write automated tests so TDD isn’t always an option.

One of the other beautiful benefits of developing offline is that it reduces the potential conflict between team members who may be using the same functions. While running locally it won’t be deploying to the cloud and won’t be interacting with the actual API gateway so none of your changes will break the development environment.

Running Lambda Locally

It’s been really difficult to find a 100% match to the lambda runtime, serverless-offline is the closest I’ve ever found. serverless-offline is a serverless framework plugin that is pretty good at emulating AWS Lambda and the API gateway on a local machine.

If you are using dynamodb there’s a really great plugin called serverless-dynamodb-local.

Requirements

Your project must be using the Serverless framework and be constructed to work with it. At the very least, you should have a really basic knowledge of how the framework works and how to use it to speed up development.

In the shell / terminal or command prompt you should be able to tell if you have it installed correctly be running

serverless --version

If it responds with a version number you definitely have it working correctly and should be good to go!

You will also need to have NodeJS Installed and need to understand the basics of the language.

From the shell / terminal / command prompt you can tell if you have NodeJS installed by running

node -v

It will return back with a version number if it’s installed correct. I recommend having at least NodeJS version 10 installed.

Installing the serverless-offline version into your project is pretty easy. From the root of the project in the terminal run

npm install serverless-offline --save-dev

In the serverless.yml file which should be located in the project root you’ll need to add it to the plugins, like so

plugins:

  - serverless-offline

If you are using other plugins you should have serverless-offline listed as the last plugin as it needs to run last.

To use serverless-offline you’ll need to run the following command from the terminal in the root of the project.

serverless offline start --s {yourStageNameGoesHere} --r {whateverRegionYouUseGoesHere}

So if I had a stage name of dev and a region of us-east-1, I would run the command like this:

serverless offline start –s dev –r us-east-1

When the server starts successfully you should see a breakdown of all of the possible routes and what’s what url to call it from. For example,

Serverless: Starting Offline: dev/us-east-1.

Serverless: Routes for app:
Serverless: ANY /
Serverless: ANY /{proxy*}

Serverless: Offline listening on http://localhost:3000

I typically use Postman while I’m working updates to the API to call the endpoints with as I find it’s really easy to use with JSON and requires a lot less typing than things like CURL.

Summarizing

There’s quite a few serverless plugins that are available that will allow you to simulate a lot of the AWS stack locally so you can develop locally without necessarily having to need access to AWS.

Changes can potentially become visible a lot faster without having to wait for deployments to happen and this allows for much shorter development and test cycles.