Zero to Production Node.js on Amazon Web Services

Kevin Whinnery begins his “Zero to Production with Node.js” course by walking through the course agenda. His goal is to leave you with the skills to build a Node production environment that is productive in development and won’t fail under a modest load.

Kevin will be using the TodoMVC front-end application throughout the course. He spends a few minutes talking about how the application will work and what he’ll be doing to migrate the application from only running on the front-end to leveraging the server capabilities within a Node.js environment.

In this exercise, Kevin walks through the initial setup of the TodoMVC++ application. He describes the purpose of each directory and talks about how he’ll be using Grunt as the task runner for the project. After the brief walkthrough, he installs and runs the application from the command line. Then, Kevin spends a few minutes troubleshooting some installation issues.

The TodoMVC++ application will be using Express for routing HTTP request to and from the Node server. Express is often referred to as “Middleware” since it handles HTTP requests between the client and the server.

Kevin goes through a brief code demonstration of some of the key features of Express. He creates a basic application with route handling. Then he compares an inline-middleware model with a more modular approach. Using modules make the middleware more pluggable and easier to maintain.

Express is not the only HTTP Request handler in the Node ecosystem. Kevin talks through a few Express alternatives like Hapi, Sails, and Koa. These alternative frameworks require different levels of configuration and may be more or less complex than Express. Kevin recommends choosing a framework that best-fits your development style and requirements.

In this exercise, you will work with the Express framework in the TodoMVC++ application. You will modify the headers sent by Express, create a logging middleware, and add “X-Shenanigans-None” to all API requests. Tasks for this exercise are located in the Issues section of the Github project and labeled “Exercise1”.

Kevin walks through the solution to Exercise 1.

NPM scripts are a part of the Node environment. They require no additional installation and provide a conventional method for running local binary commands. Grunt tasks add a mature plugin ecosystem and are good at synchronous execution. The TodoMVC++ application will be leveraging both NPM scripts and Grunt tasks.

The deployment environment, which Kevin will be covering later in this course, is Elastic Beanstalk. The NPM scripts that are used by Elastic Beanstalk are start, prestart, and poststart. These scripts start the Node process and run any necessary commands before and after the process has started.

Kevin spends some time walking through the current NPM scripts included in the application. Along with the start and prestart scripts, a test script is included which will run the Mocha test runner. After looking at the NPM Scripts, Kevin introduces the the Grunt tasks and looks how they are configured in the Gruntfile.js file.

Two alternative task runners to Grunt are Gulp and Webpack. Gulp leverages streams which can be faster and has a more code-like syntax as opposed to Grunt’s configuration file. Webpack, which integrates with Grunt tends to add more frontend features and is less of a general-purpose task runner.

In this exercise, you will add an NPM script as a shortcut for the Sequelize migrate command. You will also uglify the JavaScript application code during the build process with Grunt. Tasks for this exercise are in the Github project’s issues and labeled with “exercise2”.

Kevin walks through the solution to Exercise 2.

The TodoMVC++ application will be using the PostgreSQL relational database for storing data and the promised-based Sequelize for the object-relationship mapping. After introducing these tools, Kevin talks about the advantages of using SQL over NoSQL databases like Mongoose.

Kevin looks at how the database is currently configured in the TodoMVC++ application. The .sequelizerc file feeds the default configuration and migration paths to Sequelize. The database.js file contains the specific development, testing, and production server information. Kevin also spends a few minutes explaining migrations and looks at one of the generated files.

Before moving on to the next exercise, Kevin talks through a couple database alternatives. MongoDB and Mongoose both natively support JSON data so no migrations are necessary. Kevin prefers Mongoose due to the added resources available.

In this exercise, you will be enhancing the data model with a few additional properties. You will add a Boolean status property to the Todo model. You will also write an integration test to validate the controller and model are working properly. Tasks for this exercise are listed in the Issues section of the Github project. They are labeled “exercise3”.

Kevin begins walking through the solution to Exercise 3. In this part, Kevin creates a migration which adds a boolean property to the Todo model.

Kevin completes the walk through of Exercise 3. Now that he’s added the new boolean property, Kevin adds an additional integration test to ensure the model and controller are working properly.

There are a variety of services available for deploying an application. There are managed environments like Firebase or Heroku and more hands-on environments like Digital Ocean. After a little background, Kevin introduces Amazon’s RDS product and discusses why he’ll be using Elastic Beanstalk to deploy the application to RDS.

Provisioning an environment includes selecting a region in AWS and creating a user with sufficient permissions. After that an RDS instance can be added and a security group configured to allow incoming connections to Postgres. Once that’s all in place the application can be deployed with Elastic Beanstalk.

Kevin begins a lengthy demonstration of creating the production environment and deploying the application. He first logs into the AWS console and selects a region for the deployment. He then creates a user and puts the user in an “admins” group.

Kevin continues his deployment demonstration by creating the Elastic Beanstalk application. He uses the command line utility to generate the application and set up the EC2 environment instances.

With the EC2 environment now in place, Kevin uses Amazon’s RDS service to launch a new database instance. He creates a Postgres instance the walks through the configuration of the instance identifier and master username/password. While waiting for the database to initialize, Kevin finishes some of the Node environment configuration for the Elastic Beanstalk application.

Kevin concludes his deployment demonstration by finalizing the PostgreSQL connection settings and running the “eb deploy” command to initiate the Elastic Beanstalk deploy script.

Before jumping into the exercise, Kevin covers the pros and cons around some of the alternatives to Amazon’s AWS/RDS environment. He looks at fully managed services like Heroku and more dev-ops intensive services like Digital Ocean.

In this exercise, Kevin gives the audience a chance to get their own production environment configured. He walks through the entire process again while answering audience questions along the way. In this first part, Kevin provisions the environment and creates a user.

Kevin continues walking through Exercise 4 which revisits the process of creating the application’s production environment. In this part, Kevin initializes and configure the security group.

In the final part of the exercise 4 walkthrough, Kevin completes the Elastic Beanstalk configuration by creating a virtual directory for the static assets and adds the environment properties. Finally, Kevin runs the “eb deploy” command to deploy the application and views it running on the production server.

Kevin kicks of the second day of his Zero to Production with Node.js workshop by talking through the agenda. In response to an audience question, Kevin also describes at a high level the way administrators would store application credentials in S3 so individual developers do not have direct access to them.

The main purpose of Browserify is to enable the use of CommonJS modules in the browser. This allows for the creation of more isomorphic web applications. In the TodoMVC++ application Browserify is also using a Babel transform which compiles ES2015 (ES6) syntax into the ES5 equivalent making it more cross-browser compatible.

SASS, or Syntactically Awesome Stylesheets, is a superset of CSS with better modularization and built-in logic/helper functions. SASS is compiled into valid CSS code during the build process. After introducing SASS, Kevin talks about LESS which is a SASS alternative. He also comments on other front-end design frameworks like Twitter Bootstrap and jQueryUI.

Kevin demonstrates how Browserify is added to a project and how to use a Browserify transform for compiling Markdown into HTML. After installing the transform locally in the project, Kevin adds “browserify-markdown” to the package.json file and requires the README.md file in the project.

Kevin continues the Frontend Toolchain code demo by looking at SASS. He looks at nesting, variables, imports, and mixins. After editing an SCSS file, Kevin moves over to the browser to look at how it was compiled into valid CSS for the browser.

In this exercise, you will update the styles for the TodoMVC++ application by editing the SCSS files. You will also add an ES2016 preset to the Babel configuration. The tasks for this exercise are labeled “exercise5” in the Issues section of the Github repository.

Kevin walks through the solution to Exercise 5.

Vue.js is a frontend JavaScript framework. It adds features like two-way data binding, HTML directives, and is very component-oriented. Kevin introduces these features of Vue.js compares it to other frameworks like jQuery, React, and Angular.

Kevin spends a few minutes demonstrating how to use Vue.js by building very simple version of a Todo application. He links the Vue component to an HTML element and adds bindable todo item data as well as a public method for adding todos.

In this exercise, you will updated the client-side code in the TodoMVC++ application. You will add light and dark themes to the Todo user interfaces. You will also persist the “completed” status of the Todo items using the REST API. Tasks for this exercise are labeled “exercise6” in the Issues area in the Github repository.

Kevin begins walking through the solution to Exercise 6. He starts by looking at the correct way too implement managing the completed status in the user interface.

Kevin continues looking at the solution to Exercise 6. In this part he implements the light and dark themes for the Todo user interface. He also adds two radio buttons for toggling between the light and dark themes.

Socket.io is the de-facto standard for real-time functionality in Node.js applications. It contains both a client-side and server-side libraries to implement event-driven interactions over web sockets.

To demonstrate how to use Socket.io, Kevin builds a simple chat application from scratch. He begins by creating the basic Express web server as well as a client-side page for adding chat messages and viewing the chat log.

Kevin continues the chat application code demo. In this part, Kevin adds the Socket.io library into the Express application. He then uses the “emit” method to send chat messages to any other connected clients. Finally, Kevin uses the NGROK utility to make his local web server available for the audience.

In this exercise, you will update the TodoMVC++ application so the todo list for new todo items is updated using web sockets. The task for this exercise is located in the Issues area of the Github repository and labeled “exercise7”.

Kevin walks through the solution to Exercise 7.

Kevin introduces Locust and Rollbar. Locust is a Python-based tool with a very large and mature community. Locust simulates different types of load on an application. Rollbar is a third-party service for tracking exceptions in server-side applications. It has built-in integration for Express and a customizable API for client applications.

Kevin demonstrates how to use Locust to simulate user traffic on the Elastic Beanstalk hosted TodoMVC++ application. Locust runs a local web server allowing developers to input the number of user to simulate and how many users to spawn per second. Once the “swarm” is started, Locust will display realtime data of the load test.

In this exercise, you will add Rollbar integration to the TodoMVC++ application. Any exceptions occurring in the the production environment will be sent to Rollbar. The task for this exercise is labeled “exercise8” in the Issues area of the Github repository.

Kevin walks through the solution to Exercise 8.

Analytics are an important tool for checking assumptions on how an application is used as well as optimizing key workflows. This leads to a better understanding of how and application is being used. Kevin introduces Google’s Universal Analytics and talks about a few of its key features.

Kevin walks through the Google Analytics user interface and highlights a few of the areas he thinks are most valuable. He then explains how custom events can be reported to Google Analytics via JavaScript to track user interactions like button clicks or specific application features. He also introduces the custom reports feature which makes aggregating data from multiple ares easier.

Goals in Google Analytics are desired outcomes for users on a website or web application. This can be purchasing a product, visiting a page, or playing a video. Creating a custom report around a goal makes this data more easily accessible.

Kevin introduces the universal-analytics NPM module which adds support for pages views and custom events in any Node application. Custom events are organized by category, action, or a specific label.

In this exercise, you will implement Google Analytics in the TodoMVC++ application. You will track custom events for Todo filters and include page view tracking for the production version of the application. Tasks for this exercise are labeled “exercise9” in the Issues area of the Github repository.

Kevin walks through the solution to Exercise 9.

Kevin wraps up his workshop by answering an audience question about load testing the PostgreSQL database. He also shares a few final thoughts about running production Node applications.