Learn the skills you will need to be be an effective member of a development team

Building personal projects is always very different from working as an employee as part of a team. There are things that you can do on your own projects that you probably shouldn’t do at work ( like pushing to master ). This is absolutely fine as these are your projects and being able to quickly iterate over an idea and learn is the most important thing.

If you’re just getting started with Serverless and AWS then I would recommend this article first. Build 2 or 3 projects using Serverless and then come back to this article and productionise one of them.

There are also things that you’ll do at a company that you’d usually never have to think about when you are working on your own projects. In this article I’ll cover what those differences are and how you can set up one of your environments so that it works in a production ready way.

Why Productionised Environments are Different

When you are working as part of a team who are building a product that the company is selling, there are a few things that impact the way that you have to work:

• Downtime is lost money – every time that something causes the product to break your company is earning less money. If a bug causes your product to be offline for 2 days it can have massive implications. Your company could lose clients or users, miss out on event fees, or even get sued.
• You are (usually) on a team – if you deploy from your machine without having pulled the latest code down you could end up breaking something.

What this Article is going to Cover

• Running your Serverless application on your own machine with Serverless Offline.
• Unit Testing in with DynamoDB
• Integration testing
• Continuous Integration and Deployment with CircleCI

Starting Code

To start this project we need to have a codebase to start with. This video covers the code or you can carry on reading where I’ll give an overview of the repo.

The code to start this project is here. To download this repo run this command wherever you want the folder:

git clone git@github.com:SamWSoftware/ProductionReadyServerless.git

This repo is relatively simple, there is a single serverless.yml file at the root of the account that contains all of the function and dynamo definitions. There is a lambdas folder that contains an endpoints folder and a common folder. The common folder contains functions that we need to use for multiple APIs.

Serverless Offline

Now that we’ve got the code we’re ready to start with our first production ready feature: Serverless Offline.

When you’re working on a personal project, it’s usually fine to make a change, deploy it and then test that the deployed code has worked. When you’re working on a product that people use and rely on you can’t take those chances. Even if you have different environments for production and development, you don’t want to break development for your colleagues.

To resolve this issue you want to be able to test your change on your own machine and make sure that they are working before you deploy anything. We’re going to do that with Serverless Offline and Serverless DynamoDB Local.

The first thing we need to do is install both plugins:

npm install --save-dev serverless-offline serverless-dynamodb-local

We also need to add those to the list of plugins in our serverless.yml file.

plugins:
        - serverless-webpack
        - serverless-offline
        - serverless-dynamodb-local
    

For all of the endpoints that just use lambda we can now run them locally. In your terminal run sls offline start and you will see that your APIs are available on http://localhost:3000. Unfortunately, APIs very rarely use just the Lambda code and for us, wen can’t test any of these APIs just yet.

To get DynamoDB local working on our machines we need to do a few things. The first is to install the Java Runtime Environment (JRE). When we run DynamoDB local, we are actually creating a small Dynamo server on our computers and connecting out code to that.

Install the JRE from here.

You also need to run sls dynamodb install which will pull the config needed to run the dynamodb server.

Once that has been installed we can move onto getting our code ready to work with DynamoDB local. We need to make a change to the lambdas/common/Dynamo.js file to tell our code to use the local Dynamo tables.

let options = {};
    if (process.env.IS_OFFLINE) {
        options = {
            region: 'localhost',
            endpoint: 'http://localhost:8000',
        };
    }
    
    const documentClient = new AWS.DynamoDB.DocumentClient(options);
    

This is the code that we need to put at the top of our Dynamo.js file. This code is checking if we are running offline. If we are it sets the dynamo configuration options to use the local Dynamo server. This is the only change to the code that we need to get DynamoDB local working.

The last thing we need to do is to tell Serverless how to run the DynamoDB tables. Inside our serverless.yml file we need to add some extra config to the custom section.

    dynamodb:
            stages:
                - dev
            start:
                port: 8000
                inMemory: true
                migrate: true

With this all completed, we are ready to test out the code locally. To do this we can run sls offline start again. With this started up we can use Postman to make requests to our APIs.

If you start getting an error message of ERROR in Entry module not found: Error: Can't resolve './src' in... when running sls offline start then you can modify your webpack config like this to resolve that issue.

// webpack.config.js
    const slsw = require('serverless-webpack');
    
    module.exports = {
      ...
      entry: slsw.lib.entries,
      ...
    };

As you can see we are able to make requests to our APIs that work exactly as expected. We can create records and then get them later on. If we go into our AWS console you can see that this isn’t just using your existing table.

Now you have a setup which allows you to test any changes you make to your API before you ever deploy it. You can actually use this to test a new project before you first deploy it. This is good when you need to test a concept but don’t want to add extra clutter to your AWS account.

You can use this to test any API where you just use Lambda or use Dynamo. This includes hitting external APIs. There are still a few limitations with this system so it won’t work when you want to test with other AWS services. There are ways around this but that is for another article.

Unit Testing

The next step in creating our production ready project is to add automated testing. When adding testing to any project, the best place to start is unit testing. This is because it is testing the smallest sections of code. Even just implementing unit tests throughout your project will catch lots of bugs or issues down the line.

To get started with unit tests in Serverless we need to choose a testing library. Testing libraries make the writing of tests much quicker and easier. For this tutorial we’re going to be using Jest as it is the most popular and feature-rich testing library at the moment.

The first thing we need to do is to install jest:

npm install --save-dev jest

And now we need to create a jest.config.js file in the root of our project that looks like this. We use verbose: true to increase the amount of information that we get about our tests. If you find the amount of information too much, you can set verbose to false.

module.exports = {
        verbose: true,
    };
    

With that done we can now start writing our first tests.

Integration Testing

Continuous Integration and Deployment with CircleCI