Skip to content

Latest commit

 

History

History
19 lines (18 loc) · 3.17 KB

theothermattm.md

File metadata and controls

19 lines (18 loc) · 3.17 KB
Raw

Matt's Soapbox of Node.js Practices

  • Use an LTS version of node, not simply just "the latest version"
  • Prefer the use of a logging library rather than the console. Even if using a logging framework over the console seems like overkill at first, its not hard to setup, and having the ability to dial logging levels up and down and output logs to different formats easily will benefit the project over time. We have had good luck with winston
  • Prefer Express.js over other newer or less widely used frameworks. We want to strive for familiarity when other developers take over a codebase. This is one of the few exceptions to the "no specific tools" rule we have in this document.
  • Don't roll your own auth. Prefer the use of a well-supported library like Passport for authentication related stuff.
  • Don't roll your own configuration management. Prefer a library like dotenv-safe for managing secrets and configurations. We've found that dotenv-safe is a great way to do this, while making sure that the app fails fast upon startup if a required configuration is not available.
  • Don't roll your own request validation. Use a validation framework (like joi or something similar)!
  • Prefer the use of a controller layer dedicated to manipulating req/res and the next() callback. Do not let those bleed into any sort of meaningful logic. Separate those out into different modules (Services)
  • When possible and useful, prefer separating persistence logic into its own layer. (Repositorys)
  • ORM's - Most of us use ORM's for database access. But, we can't seem to come to a consensus on the best ORM to use for node these days. Our current opinion is that most of them suck. Here's some thoughts based on our experience:
    • Sequelize is the big kahuna in this space, but its kinda hard to use and its features are limited
    • TypeORM is good if you're using TypeScript, and is very full featured, but we've found it's difficult and picky to setup and while it does a lot of things, it doesn't do many things particularly well.
    • TODO what else?
  • Prefer handling errors in one place: middleware. Throw error objects in code and let middleware catch them and translate them into a standard format for HTTP status codes.
  • Have automated tests using a well known framework. Many at Dept Engineering prefer Jest. Even if it's better, don't use an obscure one. We want to make sure that we're handing over things that are easy to maintain for clients.
  • Consider using one of our boilerplates as a starting point which take many of these preferred practices into account and have already been laid out for you: