5 common mistakes in every Node.js app
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:
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.
5. Not having debug features built-in
Things will go wrong sooner or later (at this point it shouldn’t be a surprise) and when that happens it’s extremely useful to be able to troubleshoot your application without the need of a restart/redeploy. Some of the features I imagine you could toggle on/off on your process for greater insight: logs levels, tracing, metrics collection, etc. Another handy option would be to get the number of active handles (
process._getActiveHandles())or what’s keeping your process running (using mafintosh’s module).
If you want to read more on this issues here’s a list of resources:
- Production best practices from Express.js maintainers
- Everything You Wanted To Know About package-lock.json But Were Too Afraid To Ask
- Understanding lock files in npm5
- Auditing package dependencies for security vulnerabilities
- Comparing NPM Audit with SNYK
Have you seen other common mistakes? Do you have alternative solutions to these problems? Let me know in the comments!
Thanks Sherman, Jorge and Mati for reviewing a draft of this article.