This is an example API built with the Serverless Framework and Go.cd pipeline support. This Session API example creates user accounts and short and long-lived sessions using JSON Web Tokens. Details can be found in the API Reference.
This API example was featured in a talk during AWS Re:Invent 2016: https://www.youtube.com/watch?v=yErmil00DYs. A walkthrough of the Serverless Framework and build pipeline begins at 37:30.
- Node.js
- AWS Lambda, API Gateway, and DynamoDB
- The Serverless Framework v1.0
- The Go.cd build pipeline
- Unit testing and static analysis with Gulp, Mocha, Sinon, Proxyquire, and JSHint
- Code coverage with Istanbul
The Serverless Framework v1.0 provides two tools that speed up serverless development and deployment:
- The serverless.yml file defines all API Gateway and AWS Lambda function bindings as well as DynamoDB resources required to store user and session data. More information about serverless.yml can be found in the Serverless Framework Development Guide.
- The Serverless CLI provides utilities to deploy whole API stacks and individual endpoints into an AWS account. This tool is used by the Go.cd build server for Continuous Deployments.
The Go.cd server executes a per-function pipeline for automated testing, code coverage, and deployments. We're using Tomasz Sętkowski's Go-CD Yaml Plugin to define all pipelines via the pipelines.gocd.yaml file. More information about our pipeline definitions can be found here: Definining Lambda Pipelines. An example installation script for setting up your own Go.cd server can be found in the go-serverless repository.
Gulp is our task-runner of choice; test and lint tasks are defined in gulpfile.js. We've also defined a pre-commit git hook that will execute these test and lint tasks on git commit using the git-guppy and guppy-pre-commit packages. The pre-commit hook will be created on npm install.
The following libraries and packages are used for executing tests:
Unit tests live in the same directory as the code that they are testing and follow a *.test.js convention. The createSession.test.js file is a good example to reference.
JSHint is used for linting/static code analysis and instanbul provides code coverege, with help from the nyc command-line tool (used by the build server to run code coverage during pipeline deployments).
- Application resources are defined in serverless.yml.
- Build pipelines are defined in pipelines.gocd.yaml.
- VPC and NAT Gateway resources are defined in aws-vpc.template.
- A "create-vpc" pipeline on the build server will execute this template on-demand
Microservice architectures adhere to the following principles:
AWS Lambda supports resource isolation by hosting each Lambda function in its own set of containers with its own resource allocation (CPU and Memory). A Lambda function's resource allocation is defined using the "memorySize" field for that function in serverless.yml (see docs for details).
Deployments occur on a per-function basis: a function supporting a particular API endpoint can be deployed independantly of functions supporting other API endpoints.
The Continuous Integration/Continuous Delivery pipeline found in this example is designed to support the microservices pattern. Each Lambda function is independently tested and deployed (while any shared code is tested across all Lambda functions).
Each Lambda function passes through 8 stages:
- unit testing
- linting
- code coverage
- automated deployment to the development environment
- staging for test environment deployment
- manual deployment to test environment
- staging for prod environment deployment
- manual deployment to prod environment
Steps 4, 6, and 8 deploy the Lambda function as well the API Gateway interface for the function.
All Lambda function pipelines are grouped together in Go.cd, with the build status of each stage visible (green):
