Our AWS Lambda Toolbelt

Here at Olson Digital, our Innovation Team makes heavy use of AWS Lambdas.  They are a great way to encapsulate modular and potentially disposable functionality, giving us the ability to quickly try out ideas.  Combined with system mechanisms like the IoT Gateway, API Gateway, SNS, and Kinesis, they allow new functionality to be added, tested, and abandoned if necessary, with limited cost, risk, or impact to a larger system.

Since we use them so much, we’ve developed a set of tools facilitating rapid scaffolding, testing, and deployment of Lambdas.  While excellent frameworks exist to attempt to organize Lambda developments such as Serverless for the API Gateway, our toolbelt aims to be a lightweight, simple way to produce code that you don’t care about throwing out later.  

It may seem odd that I’m putting such an emphasis on the disposability of Lambdas but that is a feature that makes them very attractive.  In an environment where you are trying to innovate, you are going to end up throwing out a lot of spaghetti that happens not to stick to the wall and you are going to want a toolset and development workflow that minimizes the cost and heartache involved in the disposal.

I’m really burying the lede at this point, so let’s get down to business.  Here are four tools which currently constitute our “Lambda Toolbelt”.  We’re adding new stuff all the time, so watch the https://github.com/OlsonDigital Github organization for updates.

AWS Lambda Toolkit

https://github.com/OlsonDigital/aws-lambda-toolkit

The AWS Lambda Toolkit aims to simplify deployment and testing of AWS Lambdas.  For deployment, it exposes methods to deploy code handling, the task of zipping up only the necessary dependencies, and looking up appropriate AWS credentials either from your user configuration or project configuration.  For testing, it lets the developer define test objects, simulating the events which will hit the Lambda in production, and executes them similar to the “Test” feature of the AWS Lambda Console.

You can read all about the various methods exposed and configuration options in the project’s README.

Simple AWS Lambda Generator for Yeoman

https://github.com/OlsonDigital/generator-simple-aws-lambda

While the AWS Lambda Toolkit is great, it does require a certain amount of upfront setup, and our goal is to remove any non 0 amount of upfront setup.  To that end, we created a Yeoman generator which produces the scaffolding for a Lambda project.  This scaffolding includes:

• Initial configuration for the AWS Lambda Toolkit

• A stubbed out event handler

• Unit test configuration using MochaJS and ShouldJS

• A stub unit test

Given this, we’re able to quickly spin up a Lambda, write an event handler, and slap it onto the end of a Kinesis event stream or have it answer to an API Gateway method with little cost.

This generator sets you up with all of our toolbelt except the API Gateway Errors (since those are specific to Lambdas responding to the API Gateway).

The project README details all input options as well as steps for usage.

Promised Lambda Context

https://github.com/OlsonDigital/promised-lambda-context

Running tests against the Lambda is fine in most development environments, however, it is tricky, because it may actually affect the system since you are actually executing the Lambda.  Because of that, you really want to be unit testing your Lambdas using a true unit testing framework.  Ultimately, the result of calling a Lambda is the execution of one of the completion methods on the Lambda context.  The Promised Lambda Context is fulfilled on a call to succeed or done and is rejected on a call to fail, letting you use promised-based unit test assertions - much more convenient than having to cobble together mock contexts with appropriate assertions against all of the possible callbacks.

At the risk of sounding like a broken record, I will indicate that usage is explained in the project’s README.

AWS API Gateway Errors

https://github.com/OlsonDigital/aws-api-gateway-errors

One of the steps in configuring methods in the API Gateway is mapping Lambda results to HTTP response codes.  We wanted to remove the guesswork and decisions around mapping of error response codes and as such produced a set of custom errors mirroring the 4xx and 5xx level HTTP status codes with stringified results beginning in the numerical HTTP status code.  Given this, we always know that our mapping for “Not Found” should be “404*” across all of our API Gateway methods.

While there’s not much more information to provide than that about the module, you might find something in the README for this project as well.

Combining these tools we’ve found we are able to quickly add new functionality to a rapidly evolving system using AWS Lambdas with near zero overhead.  We are regularly updating these tools and releasing new ones as our needs and ambitions grow and shift.  To keep up to date, check out https://github.com/OlsonDigital  and keep an eye on this blog