Building Enterprise JavaScript Applications

Learn to build and deploy robust JavaScript applications using Cucumber, Mocha, Jenkins, Docker, and Kubernetes

Daniel Li

• Publisher: Packt Publishing
• Year: 2018
• Print ISBN: 9781788477321
• eBook ISBN: 9781788472913
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in JavaScript
• Index: Computer Science

Strengthen your applications by adopting Test-Driven Development (TDD), the OpenAPI Specification, Continuous Integration (CI), and container orchestration.

Key Features

• Create production-grade JavaScript applications from scratch
• Build microservices and deploy them to a Docker container for scaling applications
• Test and deploy your code with confidence using Travis CI

Book Description

With the over-abundance of tools in the JavaScript ecosystem, it's easy to feel lost. Build tools, package managers, loaders, bundlers, linters, compilers, transpilers, typecheckers - how do you make sense of it all?

In this book, we will build a simple API and React application from scratch. We begin by setting up our development environment using Git, yarn, Babel, and ESLint. Then, we will use Express, Elasticsearch and JSON Web Tokens (JWTs) to build a stateless API service. For the front-end, we will use React, Redux, and Webpack.

A central theme in the book is maintaining code quality. As such, we will enforce a Test-Driven Development (TDD) process using Selenium, Cucumber, Mocha, Sinon, and Istanbul. As we progress through the book, the focus will shift towards automation and infrastructure. You will learn to work with Continuous Integration (CI) servers like Jenkins, deploying services inside Docker containers, and run them on Kubernetes.

By following this book, you would gain the skills needed to build robust, production-ready applications.

What you will learn

• Practice Test-Driven Development (TDD) throughout the entire book
• Use Cucumber, Mocha and Selenium to write E2E, integration, unit and UI tests
• Build stateless APIs using Express and Elasticsearch
• Document your API using OpenAPI and Swagger
• Build and bundle front-end applications using React, Redux and Webpack
• Containerize services using Docker
• Deploying scalable microservices using Kubernetes

Who this book is for

If you're a JavaScript developer looking to expand your skillset and become a senior JavaScript developer by building production-ready web applications, then this book is for you.

Robust Infrastructure with Kubernetes

In the previous chapter, we used Docker to pre-build and package different parts of our application, such as Elasticsearch and our API server, into Docker images. These images are portable and can be deployed independently onto any environment. Although this revised approach automated some aspects of our workflow, we are still manually deploying our containers on a single server.

This lack of automation presents the risk of human error. Deploying on a single server introduces a single point of failure (SPOF), which reduces the reliability of our application.

Instead, we should provide redundancy by spawning multiple instances of each service, and deploying them across different physical servers and data centers. In other words, we should deploy our application on a cluster.

Clusters allow us to have high availability, reliability, and scalability. When an instance of a service becomes unavailable, a failover mechanism can redirect unfulfilled requests to the still-available instances. This ensures that the application, as a whole, remains responsive and functional.

However, coordinating and managing this distributed, redundant cluster is non-trivial, and requires many moving parts to work in concert. These include the following:

• Service discovery tools
• Global configuration store
• Networking tools
• Scheduling tools
• Load balancers
• ...and many more

Cluster Management Tools is a platform which manages these tools and provides a layer of abstraction for developers to work with. A prime example is Kubernetes, which was open-sourced by Google in 2014.

Because most Cluster Management Tools also use containers to deploy, they are often also called Container Orchestration systems.

In this chapter, we will learn how to:

• Make our application more robust by deploying it with Kubernetes on DigitalOcean
• Understand the features of a robust system; namely availability, reliability, throughput, and scalability
• Examine the types of components a Cluster Management Tool would normally manage, how they work together, and how they contribute to making our system more robust
• Get hands-on and deploy and manage our application as a distributed Kubernetes cluster

High availability

Availability is a measure of the proportion of time that a system is able to fulfill its intended function. For an API, it means the percentage of time that the API can respond correctly to a client's requests.

Measuring availability

Availability is usually measured as the percentage of time the system is functional (Uptime) over the total elapsed time:

This is typically represented as "nines". For example, a system with an availability level of "four nines" will have an uptime of 99.99% or higher.

Following the industry standard

Generally speaking, the more complex a system, the more things can go wrong; this translates to a lower availability. In other words, it is much easier to have a 100% uptime for a static website than for an API.

So, what is the industry standard for availability for common APIs? Most online platforms offer a service level agreement (SLA) that includes a clause for the minimum availability of the platform. Here are some examples (accurate at the time of writing):

• Google Compute Engine Service Level Agreement (SLA): 99.99%
• Amazon Compute Service Level Agreement: 99.99%
• App Engine Service Level Agreement (SLA): 99.95%
• Google Maps—Service Level Agreement (“Maps API SLA”): 99.9%
• Amazon S3 Service Level Agreement: 99.9%

Evidently, these SLAs provide minimum availability guarantees that range from "three nines" (99.9%) to "four nines" (99.99%); this translates to a maximum downtime of between 52.6 minutes and 8.77 hours per year. Therefore, we should also aim to provide a similar level of availability for our API.

Eliminating single points of failure (SPOF)

The most fundamental step to ensure high availability is eliminating (SPOF). A SPOF is a component within a system which, if fails, causes the entire system to fail.

For example, if we deploy only one instance of our backend API, the single Node process running the instance becomes a SPOF. If that Node process exits for whatever reason, then our whole application goes down.

Fortunately, eliminating a SPOF is relatively simple—replication; you simply have to deploy multiple instances of that component. However, that comes with challenges of its own—when a new request is received, which instance should handle it?

Load balancing versus failover

Conventionally, there are two methods to route requests to replicated components:

• Load balancing: A load balancer sits in-between the client and the server instances, intercepting the requests and distributing them among all instances:

The way requests are distributed depends on the load balancing algorithm used. Apart from "random" selection, the simplest algorithm is the round-robin algorithm. This is where requests are sequentially routed to each instance in order. For example, if there are two backend servers, A and B, the first request will be routed to A, the second to B, the third back to A, the fourth to B, and so on. This results in requests being evenly distributed:

While round-robin is the simplest scheme to implement, it assumes that all nodes are equal – in terms of available resources, current load, and network congestion. This is often not the case. Therefore, dynamic round-robin is often used, which will route more traffic to hosts with more available resources and/or lower load.

• Failover: Requests are routed to a single primary instance. If and when the primary instance fails, subsequent requests are routed to a different secondary, or standby, instance:

As with all things, there are pros and cons of each method:

• Resource Utilization: With the failover approach, only a single instance is running at ...

Table of contents

• Title Page
• Copyright and Credits
• Dedication
• Packt Upsell
• Contributors
• Preface
• The Importance of Good Code
• The State of JavaScript
• Managing Version History with Git
• Setting Up Development Tools
• Writing End-to-End Tests
• Storing Data in Elasticsearch
• Modularizing Our Code
• Writing Unit/Integration Tests
• Designing Our API
• Deploying Our Application on a VPS
• Continuous Integration
• Security – Authentication and Authorization
• Documenting Our API
• Creating UI with React
• E2E Testing in React
• Managing States with Redux
• Migrating to Docker
• Robust Infrastructure with Kubernetes
• Other Books You May Enjoy