Site is currently on development mode

5 common mistakes in every Node.js app

Last updated 1 year ago by Alejandro Oviedo


A few years ago I started working with Node. During that time I had the opportunity to work in different companies, different teams and very different scenarios: from Enterprise solutions to middle-size companies to a very wide spectrum of startups. In most of those teams I’ve found, small and big, improvements that repeated over time from one company to another. I’ve tried to shrunk them into a list of arbitrary length because I thought it could be useful to someone.

Disclaimer: each of these problems could have multiple solutions.

1. Not shutting down gracefully

This is first on the list because it’s a fairly straightforward thing to add to your application no matter if you’re using Express, Hapi or Fastify. Although it should be important for the application to not close ongoing connections unexpectedly if something goes wrong, that’s not usually the case.

Here’s a little snippet to shutdown gracefully with a native HTTP server:

``` process.on('uncaughtException', err => { console.log('something terribly wrong happened', err);

server.close(() => process.exit(1)); }); ```

2. Not auditing your dependencies

Your dependency tree could be in the order of hundreds of packages and any of those could be exposed to a vulnerability. Not checking if there are security vulnerabilities reported in your dependency tree could have a devastating impact on your application. You can get reports with npm audit or snyk.

3. Not using lockfiles

If you are willing to spend time debugging what changed from your CI/environment deployment to what you ran on your local machine that’s totally fine. If you’re not, and your goal is to get reproducible deploys, then you should be using lockfiles (either with npm or yarn).

4. Not following conventions

Not for every case following conventions should have an impact on how your application performs, but there are specific conventions that your app will use for configuration. An example is the NODE_ENV environment variable. This environment variable is used by several frameworks to, for example, avoid housekeeping chores if you’re on production. A similar scenario applies for npm, if you’re on your production environment ( NODE_ENV=production ) npm won’t install your unnecessary devDependencies which can reduce drastically your deployment time.

Read full Article