What conventions & widely-accepted libraries exist for building complex backend Node.js apps?

dzello profile image Josh Dzielak ๐Ÿ”† Updated on ใƒป2 min read

I'm starting to build a new app this month. It will be highly relational with many models like organizations, contacts, conversations. The codebase will grow quickly and in a year it will have more than a hundred models and controllers.

The frontend web and backend API components will be logically separate from the outset as there will be multiple front-ends, a public API, and a complex React app that will need to fetch and update a lot of data.

For the initial frontend, we're planning to use Next.js. The server-side rendering will be important to serving dynamic data quickly to users. I don't want to show someone a loading spinner just because they refreshed the page.

Next has some nice conventions: pages go in /pages and API routes go in /pages/api. In our case, the Next.js app will just call our API to get data and it won't have to contain all our models, business logic, and data access code. It doesn't have opinions about that stuff anyway.

Which brings me back to my main question - how is today's backend Node.js world building complex apps with models, business logic, and data access?

I've mostly built apps like this in Ruby and Rails before. This is the sweet spot for Rails and I've never felt more productive building and testing apps than with Ruby & Rails.

But I at least want to consider alternatives and see what the Node world's answer is to these questions in 2019.

Here are a few things I'm curious about:

  • Where do you put your code? How is the codebase organized?
  • On average, how many lines of code do your models have? Controllers?
  • Do you have different types of objects than models and controllers? What are they and how much code lives in there?
  • How "custom" is your setup? Does it look similar to codebases at other companies? How long does it take to get new engineers up-to-speed?
  • How good is your test coverage? How easy or painful is writing tests? Do you see engineers cutting corners? Do engineers TDD or is testing an afterthought?
  • How do your debugging tools work? Are you just doing console.log or do you use a real debugger?
  • What are the most helpful dependencies you are using? For things like authentication, i18n, data access / ORM, testing, test mocks and fixtures, model validations, sending email, receiving email, rendering views, building JSON, logging, backend jobs, pubsub
  • How mature are the dependencies you're using? How many times have you had to throw one out and build your own?
  • Does your ORM or data access layer work on the console? If you want to read or manipulate data outside your server process, how do you do it?
  • Are you using REST, GraphQL, or both?
  • Are you using TypeScript?

That's a huge list of questions so I'll stop there. Sharing your perspective on just on or two of them would be really helpful.

Posted on by:

dzello profile

Josh Dzielak ๐Ÿ”†


Co-founder & CTO at Orbit ยท Developer advocate and indie hacker ยท formerly Algolia and Keen IO


markdown guide

Tsoa has made life so much easier for me when Iโ€™ve had to build APIs that consumers could easily interact with (because tsoa builds the swagger doc for you). Also it verifies the input data at runtime which has saved a lot of pain and development cost.


Thanks for sharing! Looks like some good conventions around models and controllers. Link to tsoa.


Not many replies! :gulps: I did have someone share this with me: Node.js best practices. More of a high-level checklist but I think this would still do a good job of exposing primarily front-end devs to some intricacies of backend development, as would the canonical 12 factor app.