Node.JS applications don’t have a structure pattern and this can be tricky. if you have a lot of experience, that give you freedom to choose what is best for you. But If you’re not that experienced, you will be lost.

This post is a guide for the no experienced. Show how to structure an application that is easy to maintain and how to organize your code. For those who already know this thing, we show you some boilerplates and give you more options.

MVC boilerplate

If you are a beginner, boilerplate may be a new term. A boilerplate is nothing more that something you can copy from one context to another and, practically, nothing changes in the original.  In our case, our structure is the boilerplate. Since you can use it as a base for different types of MVC applications.

The MVC pattern has as the main feature the separation of the application in 3 layers.

  • Model: is responsible for managing all data and it’s behavior. In general, it’s where all business logic of your application it will be;
  • View: is responsible for providing the user’s interface. It will render all model’s data;
  • Controller: responsible for the communication between Model and View. At this layer that all data will be receive and then treated by model. Just like all model’s data will be pass to the view.

When  adopting an architecture pattern, it will guide the organization of your code. Some examples of the MVC influence can be seen at some frameworks like Sails.JS.

But if you are here, you aren’t using an opinionated framework like Sails.JS. So, you are responsible for defining the structure of your application.

For a small or medium application, that is subjective, bur for our purpose we will consider up until 10 entities. The following boilerplate is recommended.

project/
  config/
    routes.js
    settings.js
    index.js
  controllers/
    index.js
    movies.js
  models/
    index.js
    movie.js
  repositories/
    index.js
    movie.js
  views/
    index.jade
    movies/
      index.jade
  tests/
    controllers/
      index.js
    models/
      index.js
    repositories/
      index.js
  index.js
  package.json

As you can see, the structure is guided by layers and each one has a responsibility. The example above, we made two additions to models, views, and controllers:

  • Repositories: It’s part of the Models. It’s where the repositories, responsible for making the persistence and data recovery, will be. We prefer to separate the data access and be only a responsibility of the repository. Removing this from Model responsibility.
  • Config: the Config folder it’s only a form to organize your application. It’s there that all infrastructure configuration, like routes, and global variations, will be saved.

Now, for massive applications, it’s recommended that the layers structure is within each module. Meaning that will split our application in modules and each module is a business entity.

project/
  config/
    routes.js
    settings.js
    index.js
  common/
    index.js
  movies/
    routes/
      index.js
    controllers/
      index.js
      index-test.js
    models/
      index.js
      index-test.js
    repositories/
      index.js
      index-test.js
    views/
      index.jade
  views/
    layouts/
      index.js
  index.js
  package.json

In this example, is important to notice that each module is self-sustainable. Making easy to many teams to work in the same application.

Some changes that we make need some explanation:

  • “common” folder: even when we work with modules that know what is happening outside, you will face situations that you will reuse some codes in different modules. This codes will be at the “common” folder. For example: parsers, data manipulation functions etc.
  • We added tests inside each layer. So, we don’t need to repeat the layer structure inside of the “test” folder. This way, tests will be beside of the implementation. Making easy the access.
  • Each module exposes your routes and we still have a route folder at the config folder to add to our application.
  • We still have a “views” folder but now only to store general layouts.

API Boilerplate

When we work with Node.JS, we use to create more APIs that monolithic applications.

Your structure will be similar to what we show you but with the difference that will not have the “views” folder. So, to not be repetitive, remember: you just need to remove your “views” folder to have the boilerplate at you API.

Lib Boilerplate

To finish, we recommend this boilerplate for your lib in Node.JS.

lib/
  index.js
  mylib.js
test/
  index.js
  mylib.js
package.json

The structure is pretty straightforward. After all the lib context is smaller and layers and abstractions aren’t necessary.

Conclusion

As we see, to structure an application maybe sound difficult, but the hardest part is to decide between so many options. That’s why is good to have some references at hand. Like those we show you.