10 Best Practises in Node Applications - Part 1

akashshyam

Akash Shyam

Posted on March 6, 2021

10 Best Practises in Node Applications - Part 1

Hey guys πŸ–, Today I've got 10 conventions and practises to follow while building Node applications. Without further ado, let's get started.

Project Architecture -

Whenever you start building an application, ALWAYS think about the project structure. I've seen many people(including me) dump their files into their root directory. This causes problems later when they want to add more features or refactor. A lot of bugs can be introduced. Always go with common folder structures like MVC, MVVM etc or try a custom folder structure.

Separate express app code and server config -

In production level applications, we use a lot of middleware and routers. A thing that I like to do is separate app.listen(), DB config, environment variables etc from the routers and middleware. A quick example -

// app.js
const express = express();
const app = express();
const router = require('./routes/router');

// App Middleware
app.use(express.json());

// Routers
app.route(router);

module.exports = app;
Enter fullscreen mode Exit fullscreen mode
// server.js
const dotenv = require('dotenv');
const mongoose = require('mongoose');
const app = require('app');

// Environment variables
dotenv.config({
  path: './config.env'
})

// DB config
mongoose.connect(process.env.DB_CONNECT, {}, () => {
  console.log('DB connected');
})

// App Listening
app.listen(3000, () => {
  console.log('App running');
})
Enter fullscreen mode Exit fullscreen mode

Keep all API keys, secrets etc in environment variables -

I know, I know most of you know this but I added this for beginners and people who may not know this. Another thing, never commit these API keys to public git repos. It's ok to commit this to a private/team repo as they are probably your teammates and they probably need it to run the app locally.

Always implement error handling ASAP -

If you don't do this, you will implement a lot of features and then have to refactor everything(believe me, it's a pain).

I usually implement an AppError class that extends the Error class. The AppError also takes in a status code in the constructor. Also, don't forget to handle uncaughtException and unhandledRejection errors.

Make NPM packages of functionality used across projects -

Let's say you reimplement email functionality in various projects. You can make a NPM package or a cloud function for this. I'm always lazy when adding optimisation to my repeated functionality because I always have to reimplement it(really lazy... I know). So, you can add optimisation to your packages/functions

Implement a function for handling trycatch while using async/await -

Here's what I usually implement in projects:

module.exports = fn => {
  return (req, res, next) => {
    fn(req, res, next).catch(next);
  };
};
Enter fullscreen mode Exit fullscreen mode

NOTE:- This works only after implementing error handling

Distinguish between programming errors and operational errors -

Programming errors are errors that are caused by some bug in the code or by another package. Operational errors are error we cause intentionally in our application(eg when user submits incorrect data). As I mentioned earlier, a custom AppError can be very useful as we can add a boolean isOperational to find out the error type and respond accordingly.

Log the programming errors as they will show up in your hosting platform and help you to fix bugs. It's always good to use a Logger.

Use const and let and throw var in the bin -

Always define variables using const unless you're sure you will modify it. In case you need to change it, you can always change it to let. Using const prevents a lot of bugs.

Make a separate config directory -

No need to do this if you have only 3-4 files. However, let's say you are using Travis CI, docker and Kubernetes. You'll probably have 10-15 config files for this if you're building a proper production app. Always create a config directory to prevent clutter. This also tells team members that all the config related files are in this directory.

Remove frontend assets from Node -

I think most us of have been there when we want to create image/file uploads but don't want to pay for amazon S3. We end up dumping this inside our project directory. The image uploads can scale up and it will affect performance.

That's it for now. Thank you for reading until here, I hope you liked this post. If you did, like this post and follow me. Tell me in the comments on what topic my next post should be on. Bye πŸ‘‹

πŸ’– πŸ’ͺ πŸ™… 🚩
akashshyam
Akash Shyam

Posted on March 6, 2021

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related