5 Pitfalls to Avoid When Developing a Node.js Web Application

Warning: This article is more high-level. I'll be mentioning things people don't generally mention in an article discussing Node.js. Don't expect me to walk through the code with you. LMGTFY.


We’re going to explore the common mistakes people make when working on a new project, specifically those that affect performance, scalability, and deadlines.

Someone wants a new end-to-end web application. You get the requirements, plan out your timelines and get going. You identify the models, build the back-end, build the front-end, add features, tackle scope creep as it comes up, add more features...

Result? A tangled mess of spaghetti that gets worse as you touch it.

If this sounds familiar, stick around. Let’s dive into the common issues developers encounter that affect the actual performance, scaling, and timelines of a full-stack Javascript application.

  1. Poor Database Choice
  2. Underutilizing Build Tools
  3. Don't Repeat Yourself
  4. Ignoring the Style Guide
  5. Bloated Dependencies

1. Poor Database Choice

People like to wield stacks like creationists wield the Bible. They treat it as gospel. The alpha and omega.

They use MEAN or MERN stacks and completely skip the possibility of using a relational database. I understand the convenience of using your models to define your database when prototyping an application, but not considering all your options is irresponsible and more importantly unfair to the stakeholders.

NoSQL databases are designed to handle unstructured data (e.g., texts, social media posts, video, email) which makes up much of the data that exists today.

Directly from the MongoDB website

Problem

As you scale, the optimizations you made in MongoDB for READ operations by nesting your objects becomes the source of performance hits for WRITE operations.

$populate is a decent workaround for SQL JOINs, but once again, performance becomes an issue.

We've had to tell a client, after investigation, that their early database choice was causing massive performance issues and helped them transition to a relational database.

Plan out your schemas ahead of time and decide what would work best given your timelines and what stage your application is in.


2. Underutilizing Build Tools

Build tools are one of the things that aid our development speed. Having worked on large enterprise Java applications where servers can take minutes to restart, the quickness of the build environment in Javascript brings a tear to my eye. Shout out to JRebel for bringing the Java restart times down.

Problem

That being said, many teams are not leveraging build tools properly, impacting your development speed. I wrote an article recently touching on the popularity of build tools. But despite which tool you decide to go with, there should be certain core tasks it covers.

Make sure your build tool accomplishes the following:

  • Minifies CSS and JS for production builds
  • Minifies images
  • Uses source map files for preprocessor compiled code for dev environment debugging
  • Lints on modification - did you know you can use OS notifications for better feedback? Gulp/Webpack
  • Runs tests
  • Correctly injects dependencies
  • Injects JS and CSS to your browser on modification
  • Makes use of environment variables

You should also pay attention to CI with your development servers at the least. Check out our article on deploying Jenkins with Docker.

Need help with Web Development?

Work with Quantum Mob.


3. Don't Repeat Yourself (DRY)

You should be familiar with the term DRY. This seems like a trivial thing to mention, but we're in a unique position to have this discussion.

Problems

Code smell, spaghetti code, code bloat. It happens. Be sure to stay on top of it and optimize.

You might protest, "But, Eric. We're talking about starting a Node.js project from the ground up! Why are you talking about refactoring?"

We've taken over projects that have been built by other shops in the span of a few months that quickly got out of hand because of a lack of accountability or oversight on the developers. This is what leads to spaghetti.

Plus, one of the beautiful things about using Javascript on client and server is the opportunity to reuse the same code front to back. Utils for your models and custom libraries can be used both in your Angular app and in your Node.js server. Just be mindful that browser will have access to this code.

Modularize your code. Don't optimize too early or over-engineer, but don't ignore small changes out of laziness. You can move fast and break things a bit less.


4. Ignoring the Style Guide

Everyone always wants to dive right into the code and build as fast as possible. You'll often find as you get closer to a finished product, you’ll run into more and more styling inconsistencies that seem to materialize out of nowhere.

Problems

Not using a proper style guide for front-end patterns is a guaranteed way to create disparity throughout your HTML. This might not be a problem for you as a developer, but this can cause style inconsistencies, or worse, force you to create CSS styles on the fly to hack a solution often overlooking the correct markup for the elements.

If you can, kick off with a style guide that includes HTML and Javascript code blocks for the front-end. This is essentially what Bootstrap and Foundation are. But who wants another web app that looks like a Bootstrap admin panel?


5. Bloated Dependencies

yarn add jquery. yarn add every jquery plugin out of convenience. Need some array manipulation yarn add lodash. yarn add every package and end up using one function.

Go take a look at your massive package.json (or Bower) file.

Problem

You see what's happening here. You inflate your dependencies and end up with more requests to the server, or larger combined asset files.

It makes sense during early development to have access to the entire library you've imported because you never know when you'll need another function. But how do you intend to keep track of your usages until the time you need to optimize?

This is when it makes sense to have your own set of modular libraries. Certain JS libraries also offer a slim version with reduced functionality.

This is a bit more late game, but I think it's important to keep track of what you're using and how you're using it.


Conclusion

Starting off a project is always a balancing act of moving fast and optimizing. You want to make sure your application will perform as it grows but still hit your deadlines. We keep our balance with these key early decisions:

  • Optimal database choice - relational DB vs NoSQL
  • Configuring the perfect build setup - including CI with our dev servers
  • Modularizing code and DRY
  • Utilizing a front-end style guide
  • Being mindful when adding dependencies

There are a ton of other topics I left out, but let's keep this article short and save them for next time.

Eric Kim

Quantum Mob Co-Founder and jack of all trades.

Toronto https://qmo.io

Need help with Node.js?

Let's work together.

Subscribe to Quantum Blog

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!