# Welcome to Node.js Best Practices Welcome to the biggest compilation of Node.js best practices. The content below was gathered from all top ranked books and posts and is updated constantly - when you read here rest assure that no significant tip slipped away. Feel at home - we love to discuss via PRs, issues or Gitter. ## Table of Contents * [Project Setup Practices (18)](#project-setup-practices) * [Code Style Practices (11)](#code-style-practices) * [Error Handling Practices (14)](#error-handling-practices) * [Going To Production Practices (21)](#going-to-production-practices) * [Testing Practices (9)](#deployment-practices) * [Security Practices (8)](#security-practices)

# `Project Setup Practices` ## ✔ 1. Structure your solution by feature ('microservices') **TL&DR:** The worst large applications pitfal is a huge code base with hundreds of dependencies that slow down they developers as they try to incorporate new features. Partioning into small units ensures that each unit is kept simple and easy to maintain. This strategy pushes the complexity to the higher level - designing the cross-component interactions. **Otherwise:** Developing a new feature with a change to few objects demands to evaluate how this changes might affect dozends of dependants and ach deployment becomes a fear. 🔗 [**Read More: Structure by feature*](../errorhandling/asyncerrorhandling.md)

## ✔ 2. Layer your app, keep Express within its boundaries **TL&DR:** It's very common to see Express API passes the express objects (req, res) to business logic and data layers, sometimes even to every function - this makes your application depedant on and accessible by Express only. What if your code should be reached by testing console or CRON job? instead create your own context object with cross-cutting-concern properties like the user roles and inject into other layers, or use 'thread-level variables' libraries like continuation local storage **Otherwise:** Application can be accessed by Express only and require to create complex testing mocks 🔗 [**Read More: Structure by feature*](../errorhandling/asyncerrorhandling.md)

## ✔ 3. Configure ESLint with node-specific plugins **TL&DR:** Monitoring is a game of finding out issues before our customers do – obviously this should be assigned unprecedented importance. The market is overwhelmed with offers thus consider starting with defining the basic metrics you must follow (my sug **Otherwise:** You end-up with a blackbox that is hard to reason about, then you start re-writing all logging statements to add additional information 🔗 [**Read More: Structure by feature*](../errorhandling/asyncerrorhandling.md)

# `Code Style Practices`

# `Error Handling Practices`

⬆ Return to top

## ✔ Use async-await for async error handling * **TL;DR:** Handling async errors in callback style is probably the fastest way to hell (a.k.a the pyramid of doom). The best gift you can give to your code is using instead a reputable promise library or async-await which provides much compact and familiar code syntax like try-catch * **Otherwise:** Node.js callback style, function(err, response), is a promising way to un-maintainable code due to the mix of error handling with casual code, excessive nesting and awkward coding patterns 🔗 [**Use async-await for async error handling**](../errorhandling/asyncerrorhandling.md)

# `Going To Production Practices`

# `Deployment Practices`

# `Security Practices`