Organizing your next NodeJS+MongoDB App – Part 1

When dealing with a project of any real substance, one needs to plan (what a thought!). Often this takes place at the diagram level and perhaps even at a technology selection level. In this multi-part post, I wanted to share my method of organizing my app’s backend. In this portion, I’ll be discussing the general layout of our app and explain what each subfolder will hold. Once we’ve established that, in the next post I’ll be going into the nitty-gritty of how some of these bits fit together

Why Read This Post?

You Want Easier To Maintain Files

You don’t want your projects to become 2,000 line monster files. A good developer doesn’t just sit down and start 💩ing out code. Organizing your work into multiple, easier to understand files will slow you down in the short run, but over the life of a 3-6 month project it will pay off in spades.

Your Code Needs To Be Maintained By Someone Other Than You

It’s not just a possibility; it’s an inevitability. Having your project organized into a small set of recognizable folders/files makes wrapping someone’s head around a project much easier than having them read several unrelated files and hoping they fit them together or worse, traversing a disorganized mess of files/folders.

What You Need To Know

Actually not much for this portion! A lot of what you pick up from this post applies to programming in general.

The General Layout

Most of my mongodb+express projects involve the following files/folders

  • Server Folder
    • Schemas
      • SomeSchema.js
      • AnotherSchema.js
      • Schemas.js
    • Routes
      • SomeSchemaRoutes.js
      • AnotherSchemaRoutes.js
      • Routes.js
    • Helpers
      • WhateverYouNeed.js
      • othergoodies.js
  • Files
    • server.js
    • cluster.js


The Schema’s folder will hold all of our MongoDB schemas. Each file in this folder will describe a different schema in our database. In most cases, this suffices however in some situations where an object has many methods, I may even have a “SomeSchema” folder with a separate “SomeSchema.js” and a “SomeSchemaMethods.js” file, but more on that in the second post.

This allows us to have all of our schemas in one nice place. To tie them all together we will import each and every one of them into the “Schemas.js” file. This acts as our single access point for our schemas for the rest of our app. Ideally, this will only Routes.js, but in some rare cases, we may need to import a schema else where.


Routes will handle all of the routes of our app(big surprise huh?) So if we want to create, read, update or delete something, we do it here. Some nice benefits of this are that we can separate database logic and app logic. So if we wanted to implement an extra method from the server that doesn’t interact with the database, we can do it in a single location that is separated from the database logic. For instance, if you had a courtesy route from the app to check if a login token is still valid, you could implement that here.


This is our “doesn’t fit neatly into either category” where I usually store my JWT encrypter/validator, validator functions and the like. This is also a good place to store our various middlewares. The important part is that we put all of these miscellaneous functions in one neat area instead of rewriting them all over the place.


This is where we tie it all together. In this set of files, we import all of our routes and various middlewares. After structuring everything in the way we did we can describe our server in one neat, clean line of code. This means the next guy who comes around will understand exactly what is going on as soon as they see it. There should be no need for them to look into any of the aforementioned folders unless they wanted to understand the specific implementation of the methods.

In the next post, I’ll be going into detail in how all of these ideas fit together in the code and what I’ve described looks like.