Zero to Production Node.js on Amazon Web Services
This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Table of Contents
The Web Server
IntroductionKevin 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.
The Sample ApplicationKevin 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.
Exercise 0: Setting up ShopIn 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.
Serving HTTP Requests with ExpressThe 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.
The Web Server Code DemoKevin 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.
Alternatives to ExpressExpress 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.
Exercise 1: Hacking on ExpressIn 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”.
Exercise 1 SolutionKevin walks through the solution to Exercise 1.
NPM Scripts & GruntNPM 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.
NPM Scripts & Elastic BeanstalkThe 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.
Build Tools Code DemoKevin 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.
Alternatives & Friends of GruntTwo 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.
Exercise 2 SolutionKevin walks through the solution to Exercise 2.
Sequelize & PostgreSQLThe 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.
The Database Code DemoKevin 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.
Alternative DatabasesBefore 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.
Exercise 3: Enhancing our Data ModelIn 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”.
Exercise 3 Solution Part 1Kevin begins walking through the solution to Exercise 3. In this part, Kevin creates a migration which adds a boolean property to the Todo model.
Exercise 3 Solution Part 2Kevin 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.
Elastic Beanstalk & RDSThere 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 EnvironmentProvisioning 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.
Production Environment Demo Part 1Kevin 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.
Production Environment Demo Part 2Kevin 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.
Production Environment Demo Part 3With 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.
Production Environment Demo Part 4Kevin concludes his deployment demonstration by finalizing the PostgreSQL connection settings and running the “eb deploy” command to initiate the Elastic Beanstalk deploy script.
Alternative Production EnvironmentsBefore 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.
Exercise 4: Deploying the Application Part 1In 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.
Exercise 4: Deploying the Application Part 2Kevin 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.
Exercise 4: Deploying the Application Part 3In 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.
Front End Toolchain
Day Two AgendaKevin 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.
BrowserifyThe 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 & SASS AlternativesSASS, 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.
Browserify Code DemoKevin 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.
SASS Code DemoKevin 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.
Exercise 5: Building on Frontend ToolsIn 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.
Exercise 5 SolutionKevin walks through the solution to Exercise 5.
Vue.js Code DemoKevin 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.
Exercise 6: Building a Rich ClientIn 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.
Exercise 6 Solution Part 1Kevin 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.
Exercise 6 Solution Part 2Kevin 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.
Real Time User Interfaces
Using Socket.ioSocket.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.
Chat Application Code Demo Part 1To 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.
Chat Application Code Demo Part 2Kevin 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.
Exercise 7: Real Time FeaturesIn 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”.
Exercise 7 SolutionKevin walks through the solution to Exercise 7.
Locust & RollbarKevin 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.
Load Testing Code DemoKevin 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.
Exercise 8: Production Monitoring with RollbarIn 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.
Exercise 8 SolutionKevin walks through the solution to Exercise 8.
Google Universal AnalyticsAnalytics 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.
Google Analytics: GoalsGoals 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.
Universal Analytics in NodeKevin 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.
Exercise 9: Implement Google AnalyticsIn 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.
Exercise 9 SolutionKevin walks through the solution to Exercise 9.
Wrap-UpKevin 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.