In this post I’ll review the files that CodeStar creates for a default project. The process of starting a project is fairly simple, but if you want a walkthrough you can go to the first post in this series.

If my understanding is deficient in any area below, please let me know so I can update this post.

Source Code & Infrastructure

When the project is created, not only is the source code created, it is also put into CodeCommit for source control. Additional CodeBuild and CodeDeploy projects are created to do the build and deploy respectively (they did a good job of naming :+1:).


var express = require('express');
var app = express();

app.get('/', function(req, res) {
    "Output": "Hello World!"
});'/', function(req, res) {
    "Output": "Hello World!"

// Export your Express configuration so that it can be consumed by the Lambda handler
module.exports = app

This code sets up the Express app and sets it to respond to GET and POST requests.


version: 0.1

      - npm install
      - aws cloudformation package --template template.yml --s3-bucket $S3_BUCKET --output-template template-export.json
  type: zip
    - template-export.json

The buildspec.yml file is used by CodeBuild to package the local environment into the deployable artifact. My understanding is that the source code from CodeCommit is copied into the environment, then any commands you run add to the environment, and this environment is packaged as an artifact, a .zip file in this case.

In the build phase the ‘npm install’ command is run to setup the npm environment. The ‘aws cloudformation package’ command takes template.yml (described below) and generates a CloudFormation template.

The artifacts phase declares where to find the files included in the output of the build. The ‘files’ declaration says to grab the template that was created with the ‘aws cloudformation package’ command. I’m assuming the type: zip declaration is something special that says to zip the environment because it the source is never explicitly defined.


 'use strict';
  const awsServerlessExpress = require('aws-serverless-express')
  const app = require('./app')
  const server = awsServerlessExpress.createServer(app)
  exports.handler = (event, context) => awsServerlessExpress.proxy(server, event, context);

This code initializes the app that will be referenced by the Lambda function defined in template.yml (described below). It only exports the function handler but the definitions of what is handled happens in template.yml and the handling happens in app.js.


    "name": "express-HelloWorld",
    "description": "Hello World ExpressJS WebService",
    "version": "0.0.1",
    "private": true,
    "dependencies": {
        "express": "latest",
        "aws-serverless-express": "latest"

The package.json describes the project and includes the dependencies of the npm application. In this case ‘express’ and ‘aws-serverless-express’ are needed to run the project.

There is a README file that should be updated to describe the application.


 AWSTemplateFormatVersion: 2010-09-09
  - AWS::Serverless-2016-10-31
  - AWS::CodeStar
      Type: String
      Description: AWS CodeStar projectID used to associate new resources to team members
      Type: AWS::Serverless::Function
        Handler: index.handler
        Runtime: nodejs4.3
            !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]
            Type: Api
              Path: /
              Method: get
            Type: Api
              Path: /
              Method: post

This is a Serverless Application Model (SAM) template which is template specifically designed to describe Lambda functions so they can be deployed by CloudFormation. It describes the Resource (a Lambda function), the Handler (index.handler from index.js), the Runtime (nodejs4.3), and the Events setup API Gateway to respond to HTTP events (GET and POST in this case).

Those are the defaults which are pretty straightforward. Please email me at or tweet me @brian_yamabe. Next time I’ll add support for using TypeScript.

This will be a multi-part series on using TypeScript in an AWS CodeStar project. I don’t have the writing stamina or ability to put this all in one post. Heck, I don’t know how much I will get into each post, but I will work through what I’ve learned about getting started with on this path.

For background, I did an experiment where I implemented a Restful service with Node-TypeScript-Express, Ruby-Sinatra, Python-Flask, and Java-Jersey. You can see these over on GitHub and yes I will eventually do a writeup of my thoughts on the experiment. I was about to do another implementation of the service using AWS Lambda and Python (which feels like the most natural fit in my opinion) when AWS CodeStar was announced. I did a little poking around and found a template for creating an Express project and decided that since I enjoyed developing the Node-TypeScript-Express version of the service the most, I would use this Express template and see if I could get TypeScript to work and then make the effort to port the Node-TypeScript-Express to a CodeStar project.

Baby Steps

The first step was getting starting the project which was as simple as clicking “Start a project.” CodeStar Start

Then choosing to start an Express.js Lambda project: Express Project

After naming the project Express Project

and getting information on the CodeCommit repository that was setup Express Project

I got to the project dashboard that gives the status of the build and waited for the project to build and deploy Express Project

and then clicked on the “Application endpoint” to verify the build. Express Project

The next post will focus on the template code the CodeStar project created for us. If you have any questions or think that some aspect needs further explanation, contact me at or brian_yamabe on Twitter.

I have been using Hacker Rank for a month or so to get a feel for it. I know that some companies use it as part of their interview process so it seemed like a good idea to get familiar with it.

I like the site and think the problems are fair, challenging, and can help you to hone your development skills. That being said, a friend had me go through their version of the test they give as part of their interviewing process. I stunk at it. The problem was the timed nature of the process. When solving a Hacker Rank problem in the context of using the regular site, you can explore options, refine your code and algorithms, and have the opportunity to change directions if you start down the wrong path. In the timed interview, this just doesn’t work. I went down the wrong path on the first problem and never really recovered. It wasn’t that the problem was hard, I eventually solved it, it’s just that I thought I could do it using one data structure and then when that wasn’t working I switched to another. That just put added time pressure on the rest of the problems and I made a bad assumption on another problem that pretty much sunk the rest of my “interview.”

I understand, if not like, the need to look for a baseline of programming ability, but I feel that tests like these don’t mimic a work environment in a meaningful way that reflects any candidates ability to do the job.

What this and Developer Hegemony highlight to me is the very real need to make myself something other than a “corporate resource.”

Developer Hegemony

If you are a software developer working at any size company buy “Developer Hegemony”. It explores the way companies treat software developer today and how we stereotypically react to that treatment. It clearly argues that we are treated as glorified line-workers and that we need to move to a model where we are treated like doctors or lawyers with independent practices.

For a long time I’ve called my job a “grind” and that even if I went to a “better” company it would still be a “grind.” Developer Hegemony helped me figure out exactly why I’ve felt this way and although the way out is non-trivial I know that it’s the only way to bring joy back into software development for me.

Don't Put Your Async in My Serverless

A lot of the constructs of Node and modern JavaScript are about handling the asynchronous nature of web server/browser interactions. In a serverless world, single threaded execution is ideal and asynchronous code is problematic. While the title of the linked article (“Node is the WRONG runtime for serverless”) is sensationalist, as the author admits, the article argues Python is a better fit in a serverless world.

I was planning on implementing a project using AWS CodeStar starting from an Express template and porting an existing Express application. I then evaluated the code based on this article and found that I’m using promises for the database interactions. As the author notes, this shouldn’t be a deal killer, but I do need to be aware that using many of the asynchronous patterns common to Node and JavaScript server applications is unlikely to be beneficial in a serverless architecture and harmful from the perspective of unnecessary code complexity.