← Making home assistant work with X10... Node Reference - Unit Testing →

Node Reference - Introduction

07/02/2018 By Paul Rowe, Matt Vincent


Most AWS microservice articles only show you the tip of the iceberg. We certainly can’t blame the article authors. For starters, the SAM squirrel mascot is so darned cute!
But more importantly, we all know that standing up a production web service involves far more considerations than you could ever cover in a single article. We are talking about considerations like automated testing, CI/CD, authentication, security, telemetry, resiliency, monitoring and management.

Our aim with this series of articles is to guide you through these considerations and share with you the why and how of each. We are going to walk though each step of setting up a production-ready RESTful service on AWS. We will start with continuous integration and unit testing, cover building and deploying a reliable service, securing that service and monitoring it. Along the way, we will explain our reasoning on why we are making the choices we are making. This allows you to ask the same questions of your technology stack in order to determine not only what the “best practice” is but what problem (if any) that practice actually solves. Our opinions are driven by a few simple principles:

This series is for you if you have ever:

We will be demonstrating these concepts by building a RESTful microservice that manages “Products” for a hypothetical e-commerce platform. An example product in JSON format looks like this:

    "id": "f7dr35",
    "name": "Widget",
    "imageURL": "https://example.com/widget.png"

This application only exposes HTTP endpoints to manage this data. It is up to other applications within the organization to provide a UI on top of that data. This provides a decoupling from the data and the business rules that govern how that data behaves from the way in which data from several services is combined together into the most effective presentation. While only one application may modify products, dozens may have the need to look up product information.

While you may not be building the next Amazon.com, these concepts will be directly translatable into a service in any business domain that needs to reliably manage data.

To support these goals, we will be deploying our application using NodeJS within a Docker container on AWS.

Javascript, via the NodeJS project, is becoming a common platform for cloud services due to its lightweight runtime, familiar language and extensive ecosystem. However, most of the concepts outlined here apply equally to any modern language.

Docker provides a mechanism for repeatable deployments by creating a bundle that contains all of our source code with a known version of the underlying NodeJS runtime. We go into a more detailed explanation of these advantages later in the series.

AWS provides a large and ever-growing toolbox of services that allows us to delegate common concerns like infrastructure, networking, DNS, and data storage while focusing on the features and problems unique to our application. While all of the concepts here can be ported to other cloud providers, we (along with many others) have found AWS to have the most mature feature set among the competitors. Our company, Source Allies, has built a deep expertise in working with AWS and we are an APN Partner.


Before we get started, we will need to ensure a few things are setup on our local machine:

Initialize the project

Navigate into the project directory and run the following on the command line to create a package.json (you can answer the prompts however you choose):

npm init

It is also recommended to add the node_modules directory to your .gitignore file so that dependencies are not checked into source control.

Changes for this post

Table of Contents

We look forward to sharing our insights with you! If you have questions or feedback on this series, contact the authors at nodereference@sourceallies.com.

About the Authors

Paul Rowe studied computer science at Western Illinois University. He started working with Source Allies in 2007 and has over a decade of software development consulting experience in the Health Care and Agriculture markets. Paul is versed in a variety of Node.js, Java and AWS tech stacks. He experiments on GitHub here.
Matt Vincent studied industrial engineering at the University of Iowa. He founded Source Allies in 2002. Matt is an AWS Certified Solutions Architect & DevOps Engineer with a specialty certification in Big Data.

← Making home assistant work with X10... Node Reference - Unit Testing →
Source Allies Logo © Source Allies, Inc.