Skip to content

NodeJS Setup for Production (work in progress)

Adrian Matei edited this page Jun 1, 2020 · 8 revisions

The www.bookmarks.dev back-end API is implemented with ExpressJS, which is a fast, unopinionated, minimalist web framework for Node.js NodeJS.

Here are some things we can do in your system environment to improve our app’s performance, recommended in Production best practices - performance and reliability :

  • Set NODE_ENV to “production”
  • Ensure your app automatically restarts
  • Run your app in a cluster
  • Cache request results
  • Use a load balancer
  • Use a reverse proxy

We will discuss the checked points, as they are implemented currently and make sense for our current load.

Set NODE_ENV to “production”

The NODE_ENV environment variable specifies the environment in which an application is running (usually, development or production). One of the simplest things you can do to improve performance is to set NODE_ENV to “production.”

Setting NODE_ENV to “production” makes Express:

  • Cache view templates.
  • Cache CSS files generated from CSS extensions.
  • Generate less verbose error messages.

While the first two points make no difference for us, as we serve just a back-end REST API, we still don't want verbose error messages...

Because we have environment-specific code (like Keycloak setup), we can check the value of NODE_ENV with process.env.NODE_ENV.

Be aware that checking the value of any environment variable incurs a performance penalty, and so should be done sparingly.

To make NODE_ENV permanently set to production in Ubuntu, the underlying server for #codingmarks, we can set a system-wide environment variable in the /etc/environment file:

$ sudo vim /etc/environment

Append the following at the end of the file:

NODE_ENV=production

This is set for the whole system, rather for just a particular user.

Now logout and login again and now we can see the system wide environment variable:

$ printenv | grep NODE_ENV
NODE_ENV=production

Ensure the app automatically restarts

In production, we don’t want our application to be offline, ever. This means we need to make sure it restarts both if the app crashes and if the server itself crashes. Although we hope that neither of those events occurs, realistically we must account for both eventualities by:

  • Using a process manager to restart the app (and Node) when it crashes.
  • Using the init system provided by your OS to restart the process manager when the OS crashes. It’s also possible to use the init system without a process manager.

Use a process manager

In development, we started our app simply from the command line with $ DEBUG=codingpedia-bookmarks-api:* nodemon start. But if the app crashes, it will be offline until we restart it. To ensure our app restarts if it crashes in production, we use a process manager. A process manager is a “container” for applications that facilitates deployment, provides high availability, and enables us to manage the application at runtime.

In addition to restarting our app when it crashes, a process manager can enable us to:

  • Gain insights into runtime performance and resource consumption.
  • Modify settings dynamically to improve performance.
  • Control clustering (StrongLoop PM and pm2).

The most popular process managers for Node are as follows:

PM2

We have chosen PM2 for the moment. PM2 is a production process manager for Node.js applications, that has a built-in load balancer. PM2 allows you to keep applications alive forever and reload them without downtime, and will facilitate common system admin tasks. PM2 also enables you to manage application logging, monitoring, and clustering.

For more information, see https://github.com/Unitech/pm2.

Install PM2

$ npm install pm2 -g

Start the application

$ cd ~/projects/bookmarks-api
$ pm2 start ./bin/www

Your app is now daemonized, monitored and kept alive forever.

More about Process Management with pm2

npm is a builtin CLI when you install Node.js - Installing Node.js with NVM

References