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.
- Poor Database Choice
- Underutilizing Build Tools
- Don't Repeat Yourself
- Ignoring the Style Guide
- 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
As you scale, the optimizations you made in MongoDB for
READ operations by nesting your objects becomes the source of performance hits for
$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
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.
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.
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.
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.
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.
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.
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.