Sign In Start Free Trial

Book Overview & Buying
Table Of Contents
Feedback & Rating

Building Enterprise JavaScript Applications

By : Daniel Li

4.6 (5)

Building Enterprise JavaScript Applications

4.6 (5)

By: Daniel Li

Overview of this book

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.

Preface

Preface

Who this book is for

What this book covers

To get the most out of this book

Get in touch

Free Chapter

The Importance of Good Code

The Importance of Good Code

Technical debt

Test-Driven Development

Summary

The State of JavaScript

The State of JavaScript

Evolution of the web application

Benefits of Node.js

Summary

Managing Version History with Git

Managing Version History with Git

Setting up Git

Learning the basics

Branching and merging

Releasing code

Hotfixes

Working with others

Summary

Setting Up Development Tools

Setting Up Development Tools

What is Node.js?

Modules

Installing Node

Starting projects with npm

Using yarn instead of npm

Creating an HTTP server

Transpiling ES6 with Babel

Consolidating commands with npm scripts

Automating development using nodemon

Linting with ESLint

Committing our code into Git

Summary

Writing End-to-End Tests

Writing End-to-End Tests

Understanding different types of test

Following a TDD workflow

Gathering requirements

Setting Up E2E tests with Cucumber

Implementing step definitions

Validating data type

Migrating our API to Express

Moving common logic into middleware

Validating our payload

Testing the success scenario

Summary

Storing Data in Elasticsearch

Storing Data in Elasticsearch

Introduction to Elasticsearch

Installing Java and Elasticsearch

Understanding key concepts in Elasticsearch

Querying Elasticsearch from E2E tests

Indexing documents to Elasticsearch

Cleaning up after our tests

Summary

Modularizing Our Code

Modularizing Our Code

Modularizing our code

Adding a user profile

Summary

Writing Unit/Integration Tests

Writing Unit/Integration Tests

Picking a testing framework

Structuring our test files

Writing our first unit test

Completing our first unit test suite

Unit testing ValidationError

Unit testing middleware

Unit testing the request handler

Unit testing our engine

Integration testing our engine

Adding test coverage

Finishing up

Summary

Designing Our API

Designing Our API

What it means to be RESTful

Designing our API

Completing our API

Summary

Deploying Our Application on a VPS

Deploying Our Application on a VPS

Obtaining an IP address

Setting up a Virtual Private Server (VPS)

Running our API

Keeping our API alive with PM2

Running our API on port 80

Setting up NGINX

From IP to domain

Summary

Continuous Integration

Continuous Integration

Continuous Integration (CI)

Integrating with Travis CI

Continuous Integration with Jenkins

Summary

Security – Authentication and Authorization

Security – Authentication and Authorization

What is Authentication?

Introduction to password-based authentication

Implementing password-base authentication

Keeping users authenticated

Next steps

Summary

Documenting Our API

Documenting Our API

Overview of OpenAPI and Swagger

Defining an API specification with OpenAPI

Generating documentation with Swagger UI

Deployment

Summary

Creating UI with React

Creating UI with React

Picking a front-end framework/library

Getting started with React

Modularizing React

Summary

E2E Testing in React

E2E Testing in React

Testing strategies

Writing E2E tests with Gherkin, Cucumber, and Selenium

Routing with React Router

TDD

Over to you

Summary

Managing States with Redux

Managing States with Redux

State management tools

Converting to Redux

Summary

Migrating to Docker

Migrating to Docker

Problems with manual deployment

Introduction to Docker

Mechanics of Docker

Following best practices

Summary

Robust Infrastructure with Kubernetes

Robust Infrastructure with Kubernetes

High availability

High reliability

High throughput

High scalability

Clusters and microservices

Cluster management

Picking a cluster management tool

Control Planes and components

Kubernetes objects

Setting up the local development environment

Creating our cluster

Creating our first Pod

Understanding high-level Kubernetes objects

Declarative over imperative

Configuring Elasticsearch cluster

Deploying on cloud provider

Persisting data

Introducing PersistentVolume (PV)

Dynamic volume provisioning with StorageClass

Visualizing Kubernetes Objects using the Web UI Dashboard

Deploying the backend API

Creating a backend Service

Exposing services through Ingress

Summary

Other Books You May Enjoy

Other Books You May Enjoy

Leave a review - let other readers know what you think

Customer Reviews

4.6 (5)

5 star

80%

4 star

0

3 star

20%

2 star

0

1 star

0

Releasing code

We now have a sizable chunk of features that we can release. We should create a release branch from dev. This release branch should be named after the version of the release, prefixed by release/, such as release/0.1.0. The code to be released should then be deployed to a staging server, where automated UI testing, manual testing, and acceptance testing should be conducted (more on these later). Any bug fixes should be committed on the release branch and merged back into the dev branch. When the release branch is ready, it can then be merged into master.

No new features should be added to the release branch except bug fixes and hotfixes. Any new features, non-critical bug fixes, or bug fixes that are unrelated to the release should be committed to a bug-fix branch.

So, the first question is how do we name/version our releases? For this project...

Search

Your notes and bookmarks