How I Structured My NodeJS Projects

For most (all) of my past web development projects, I have been using PHP and Java technologies.

Architecture — Photo from Pexels

I had a hard time marrying my knowledge back then with the idea of a server-side JavaScript application.

Struggle was REAL

For those who have been working with PHP and Java technologies for web development, you know that it takes a different discipline and understanding to be able to come up with an elegant solution. Most probably, an opinionated framework is already prepared for you. The project structure is already in place and your only worries are about how to make it work.

When NodeJS came into the market, I was struggling to adapt to the latest trend in web applications development, because it was purely made with JavaScript. The JavaScript that I knew of back then was just purely client-side (Plain Vanilla JavaScript, jQuery, MooTools and many more). I had a hard time convincing myself that a JavaScript can finally run on the server-side. Imagine that!

So, if you’ve been developing your applications using a different language and would like to give NodeJS a shot, then you can relate to this article.

Requirements

In this article, I’ll be sharing how I structured my NodeJS projects. This is just one of the ways to structure your NodeJS applications. This is a collection of the different knowledge I gathered while foraging for my consumption and satisfaction from the internet.

There are thousands of ways to skin a cat. But we won’t be doing one here.

I chose this project structure because of certain requirements:

1. Modularize Components
2. Expose APIs
3. Simplify Configurations
4. Fetch Logs Easily
5. Output Webpages

- project
  - src
    - components
      - api
      - modules
    - config
    - logs
    - node_modules
    - public
      - assets
        - css
        - img
        - js
    - routes
    - util
  - app.js
  - server.js
  - package.json

Project Structure

I will be discussing the rationale behind each directory and show how it can be used together with your codes.

Components

/components

The components directory will contain all of the page controllers, modules and API controllers. The directories under the components are the api, modules and screens wherein each item serves its purpose.

1. The api directory will contain the API controllers, these controllers will call the necessary service modules. It’s expected that you group your contents by functionality. In this way, you can take advantage of working on related APIs altogether.
2. The modules directory will contain atomic services. These services will be consumed by the different API and page controllers that will render the data for consumption.

Configuration

/config

The config directory will contain all of the possible configurations for your application. May it be third party configurations, Google product configurations, logging configurations, you name it.

Logs

/logs

The logs directory will be, most of the time, auto-generated if you’re using a logging library. If you want to implement your simple logging, you can create this directory and place all logging output inside.

Note: It’s also best to save your logging output files inside specific directories signifying the date of creation and the year of creation, just so you can navigate through them easily.

Public

/public

The public directory will contain all of the application’s assets. This will be served publicly, which means that it can be accessed by anyone who has access to the application.

1. The assets directory will contain all of the HTML views, CSS, JS and media. The HTML views will render the data retrieved from the different services. The page controllers will be handling the incoming requests for processing, and for rendering the corresponding HTML views.

Note: More often than not, if you’re using a templating engine or a front-end library, you won’t probably be needing this one. Refer to the library’s documentation for more reference.

Routes

/routes

The routes directory will contain all potential routes that you want to create. You may create the routes here separately for both the web application web.js and for the API api.js to separate concerns in routing.

Utilities

/util

The util directory will contain all supporting scripts for the application. This may include, but not limited to, the following: validation, locale-strings, constants, helper functions, and many more.

Final Thoughts

It’s a very simple project structure for NodeJS applications. It’s not the only solution available out there (and I would advise you to always look for another solution and compare), but it’s always good to know and understand the reasoning behind project structures.

Conclusion

There might be other project structures out there and even better ones (others even have names) that will fit your needs. Try to adapt and adjust your solutions to cater to your needs. As mentioned, there’s no single way to skin a cat.

Software development is synonymous to problem-solving, with a dash of technology. You are not confined to a single solution. You are free to be technical and be creative at the same time, so long as you’re able to produce the right output whilst taking note of flexibility for modifications.