Serverless in Practice

In the previous post in this series, we provided an overview of serverless technologies. In this post, we’ll examine some tools for developing serverless applications and discuss creating a simple serverless application.

Serverless framework

Because of the growth in popularity of serverless platforms, a framework called Serverless has been created that allows developers to build and deploy serverless applications to any of the supported platforms. While the Serverless framework itself is powered by Node.js and can be installed using Node Package Manager (NPM), it can still be used to deploy applications written in other languages.  

Using the Serverless framework offers several advantages to developers creating serverless applications. First, the framework is provider neutral, so it can be used to configure and deploy to AWS, Microsoft Azure, IBM OpenWhisk, or others. Second, it enables developers to place all their application configuration data into a single file. This is extremely helpful when an application needs particular permissions or to have particular “resources,” such as a DynamoDB table, created on deploy. Third, the framework facilitates local testing of code. This is particularly helpful for code that is not a web application, such as event-triggered jobs or processes. Finally, the framework is extensible, and there are a many plugins that support additional functionality, such as optimization of deployment of other programming languages.

Creating a simple serverless web application

Each cloud platform supports its own set of languages. One commonly supported language is Node.js. The Serverless framework provides many robust examples of using this framework with Node. For these reasons, in addition to my existing skills and knowledge of JavaScript, I chose Node as the language to use for my work with serverless technologies.

The first serverless application I decided to create was one that uses the CONTENTdm IIIF APIs to display a digital object to the screen and create IIIF manifests based on CONTENTdm object URLs. All my development was done locally, and I could easily test the core of my application functionality by starting a local node web server. At this point in the process the code I’m writing is just regular node.js code. Nothing about the code I’ve written yet uses serverless technologies.

Once I have the core of the application complete and tested, I need to make the application run in a serverless fashion. This required adding a dependency (aws-serverless-express) and two new files (lambda.js and serverless.yml).

First, I update the dependencies in my package.json file to include:

"aws-serverless-express": "^3.1.3"

Second, I create a lambda.js file that contains the following code:

const awsServerlessExpress = require('aws-serverless-express');
const app = require('./src/server'); 
const server = awsServerlessExpress.createServer(app)  
module.exports.universal = (event, context) => awsServerlessExpress.proxy(server, event, context);

This code uses the aws-serverless-express library dependency I specified earlier to start a web server and run a Node.js Express application.

Next I need to create a serverless.yml that contains the configuration for my application. 

service: my-test-node-app 
    - local.js
    - .gitignore 
    - .git/**
 name: aws
 runtime: nodejs8.10 
 memorySize: 128
 timeout: 10
 stage: production
 region: us-east-1 

   handler: lambda.universal
     - http: ANY {proxy+} 
     - http: ANY /

This file supplies details about the application in order to deploy it. The details include the following:

  • Name of my application (my-test-node-app)
  • Handler name (lambda.universal)
  • Provider to use (Amazon)
  • Version of Node.js to run (8.10)
  • How must memory to use in the Lambda
  • AWS region and stage to deploy to
  • Events to trigger the lambda (in this case, any HTTP requests)

Once I have this, file I can deploy the application. I do this by changing into the project directory and running the command:

serverless deploy

This uploads the relevant files and properly configures the code within the AWS Lambda infrastructure. The last item in the console output is the URL for where the code is deployed and can be viewed.

Working with the IIIF API was a great beginner’s project because I didn’t have to deal with API keys and authentication. In my next post, I’ll discuss creating a serverless application that uses an authenticated OCLC API and storing API key information securely.

  • Karen Coombs

    Karen Coombs

    Senior Product Analyst