JavaScript Buzzwords Part 1: AWS Lambda and Serverless

My latest project, “Project X,” has involved me doing fun stuff with JavaScript. The project is far from being production ready, but over the next couple week I’m going to share some of the things I’ve learned along the way. When planning the project, I decided that I know very little about deploying a production quality web application. As far as I was concerned my options were: to build a giant monolith and pray that everything doesn’t break. I could watch a few Kelsey Hightower talks and build out a microservice architecture sprinkled with Docker and Kubernetes. The last was to taking on the cutting edge and use AWS Lambda.

I ruled the monolith out, because well it’s 2017 and all the cool kids told me to slay my monolith. Docker and Kubernetes would have been a great solution, if it was 2016… As much as I love watching Kelsey Hightower speak, I’m trying to eat lunch at the cool kids table. There’s nothing cooler than AWS Lambda. That was kind of a joke, in actuality I think Lambda provides the best mix between simplicity and ease of use. Also if it comes to the point that lambda functions don’t support my needs, I should be able to port the code over to another architecture. At the end of the day I’m only lightweight functions with minimal dependencies.

I like to think of lambda functions as microservices on steroids. The goal of microservice is to split your application up into tiny services, so that the developer only has to think about the service they’re working on. With lamabda functions, instead of breaking up an application into small services with you break your application up into minuscule functions. With lamabda the developer only has to think about the specific function they’re working on.

Because these functions are so lightweight they can be entirely managed by AWS. By combining these lambda functions with API Gateway developers can easily create api endpoints. Best of all AWS Lambda comes with a massive free tier. With the the decision made the goal for Project X was to use AWS Lambda as much as possible. Serverless architecture here we come.

(Serverless is a terrible name. I propose two new names: server-agnostic or server-ignorant, because it’s not that the server is gone it’s just that the developer no longer has to manage the server.)

The Serverless Framework is a great place to start with lamabda functions. There are many other frameworks and CLIs for AWS Lambda deployment. However, Serverless Framework has been around for a several years now and the team behind it is venture backed. I would argue that the Serverless Framework is the most mature framework and has the most support.

When starting with a serverless project, the first step is to globally install Serverless like so:

npm install serverless -g

(If you don’t have npm installed here’s a link)

Now you’ll have access to the Serverless Framework command line interface (CLI). Next step is to initialize your project:

serverless create --template aws-nodejs --path my-service
cd my-service
# optional initialize node modules
yarn init

Here I create a serverless application from the aws-nodejs template and I name the directory my-service. Cd into my-service and you should be ready to go. If you want to use any JavaScript packages now would be a good time to initialize your package.json file. I recommend using yarn as opposed to npm.

(For those who don’t know yarn is a project that came out of Facebook, it’s a drop in replacement for npm. Yarn is better than npm in just about everyway. Yarn using symbolic linking so your computer can cache JavaScript packages allowing it to run much faster especially when you have multiple node projects at once. Yarn also makes it impossible to add a dependency without adding it to package.json. I still for the life of me can’t figure out why npm requires you to add --save-dev and --save to add a dependency to package.json. When would I ever want a dependency to not be added?)

The aws-nodejs template we used above will give you two things, a handler.js file and a serverless.yml file.

serverless.yml (minus comments):

handler.js (minus comments):

The above code is what it looks like. The serverless.yml file declares a provider (AWS), runtime enviornment (node v6.10), and gives a path to our function (the hello function in the handler.js file). The handler.js file simply creates a response, with a 200 status code, and passes it into the callback. Callbacks are a huge part of JavaScript. Part of this is due to the fact that there are a lot of promises when dealing with JavaScript so get use to the concept of callbacks. The body is the important part of the response code. If you were to turn this into a JSON api the body is where you’d put the data that you wanted to return.

Now that everything is initialized you’re going to need the ability to deploy your application. First thing your going to need is a set of AWS keys. To obtain these go to your AWS IAM console make sure you have the region you want. Then create a user group. This is far from best practice, but what I did is created a user group lambda and attached every policy I thought I might need. (When I go to production I plan on deleting this user and creating a more isolated user group). Here’s the list of policy plans that I attached, the policies you need are in here somewhere:

• AWSLambdaFullAccess
• IAMFullAccess
• AmazonAPIGatewayInvokeFullAccess
• AmazonAPIGatewayPushToCloudWAtchLogs
• CloudFrontFullAccess
• AdminstratorAccess
• AmazonAPIGatewayAdminstrator
• AWSCloudFormationReadOnlyAcccess

Again this is not a best practice, but hey “move fast and break things.” Next click on Users in the sidemenu and create a user. Add the user to our lambda group and save their keys. Now in your project folder create and aws.keys file and make sure to add it to your .gitignore. You don’t want to share your keys with anyone you don’t trust. These keys are used to authenticate you when working with AWS so keep them safe. In the aws.keys file add your secret key and access key like so:

export AWS_ACCESS_KEY_ID="[accesss key]"
export AWS_SECRET_ACCESS_KEY="[secret key]"

Now you can run source ./aws.keys it’ll export both those values as environmental variables, giving the serverless framework access to your account. Now you’ll have the ability to run, from the command line:

serverless deploy

Give a minute or so and you’ll have deployed your first serverless application. Serverless deploy will also return a url that you can use to see the results of your application.

One key thing to remember when building serverless applications is to not overcomplicate things. You’re just writing vanilla JavaScript code. It should be easy to unit test your application using standard JavaScript testing tools like mocha or jest. If you simply pass in a mock callback functions, and mock event/context objects you can easily verify your responses. An issue I had in the beginning was I overcomplicated it. I thought there was some magic going on. I did unnecessary things like run serverless deploy every time I made a change to see if it was running properly. I wasted a lot of time, because I treated the functions like they were magic. It’s not magic, it’s just JavaScript.

I hope you enjoyed this post. Next week I’m going to get into how you can use lambda to return HTML and might even get into isomorphic JavaScript so we can render our React application on the server.