How to deploy Express applications to AWS Lambda

; Date: Sat May 19 2018

Tags: Node.JS »»»» AWS Lambda

AWS Lambda and the AWS API Gateway is a powerful combination for deploying Node.js application code on an automagically scaling deployment platform. Out of the box you do not have the Express API. This webinar shows how to setup API Gateway and Lambda to support Express applications.

With AWS API Gateway, the developer benefits are

• The ability to define a unified consistent API
• Automatic DDOS protection
• Authentication and authorization at the API Gateway layer -- The backend can trust authorization has been accomplished

With AWS Lambda, the programmer focuses on their code, and does not get caught up with DevOps drama. The Lambda function handles scaling the service to meet the request volume, and you pay only for the requests handled. An idle API service does not incur any cost. Write code, deploy code, and write a check to Amazon AWS.

Migrating an existing service to the combination of API Gateway with AWS Lambda. The organization may have an existing API implemented with a traditional deployment to a regular server. The first step of the transition is using API Gateway as a front end to the existing service. The next step is implementing Lambda functions for each of the service methods, flipping each API endpoint to use the Lambda function as the Lambda functions become complete.

An opportunity is available during that API migration process to rearchitect the API.

Some API Gateway features simplify the migration process:

• "Catch-all" resource paths -- meaning, that in API Gateway one specifies a URL pattern matching a URL prefix, and all requests starting with that prefix are sent to the same Lambda function. That Lambda one function can handle a large swath of request URL's. The advantage in migrating an existing service, is to match all the URL's from that existing service into the same service module.
• The "ANY" HTTP method -- Lets API Gateway route every HTTP method on a given URL pattern to the same Lambda function. This simplifies the service definition in the API Gateway, allowing the Lambda function to define the service.
• Proxy integrations -- Simplifies sending parameters from the HTTP request on to the service function, whether it is an AWS Lambda function, or another HTTP service. For the AWS Lambda case, it automatically configures a request mapping template to capture the all request parameters into an object sent to the Lambda function.

The downside of all these simplifications is that the Swagger/OpenAPI definition in the API Gateway does not have the complete API definition. In theory it is best for the API definition to be written with OpenAPI, so you can then generate complete API documentation from the OpenAPI specification. But if some of the API is defined in the Lambda function, the OpenAPI specification does not have the entire API.

The AWS API Gateway supports some OpenAPI/Swagger extensions to aid defining these things. Alternately, you can piece-by-piece migrate the entire API structure into the OpenAPI specification. You are not required to migrate the entire API all at once, and can do it as you have the time.

Hence the simplest possible API is for a Catch-All path for the entire API, using the ANY request type, proxying everything to an Express application.

The aws-serverless-express library "wraps" an Express application to match what's provided by API Gateway and Lambda. It works by automatically spinning up a background Express server each Lambda container instance. The aws-serverless-express library maps the incoming Lambda express into another HTTP request invoked on the background Express server.

The Lambda function implemented using this library looks like:

const awsServerlessExpress = require('aws-serverless-express');
const app = require('./app');
const server = awsServerlessExpress.createServer(app);

exports.handler = function(event, context) {
    awsServerlessExpress.proxy(server, event, context);
}

The code in app.js must initialize the Express service, but not instantiate the HTTP Server object.

While this is an excellent method to quickly migrate Express code into Lambda, it has a higher overhead because it starts a background service. Interoperating with that background service must be passed across process boundaries, adding to execution time, and incurs the memory overhead of a second process.

Github repository: https://github.com/awslabs/aws-serverless-express