10 Best Practises in Node Applications - Part 1
Tags: programming, node, javascript
Published: 2021-03-06 15:10:27

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] (https://dev.to/akashshyam/all-about-mvc-3pn7), [MVVM] (https://dev.to/akashshyam/the-lesser-known-mvvc-4g2o) 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 - 

```javascript
// 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;
```

```javascript
// 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');
})
```

### 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:

```javascript
module.exports = fn => {
  return (req, res, next) => {
    fn(req, res, next).catch(next);
  };
};
```
**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 👋