How I Structured My NodeJS Projects
For most (all) of my past web development projects, I have been using PHP and Java technologies.
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.
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.
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:
- Modularize Components
- Expose APIs
- Simplify Configurations
- Fetch Logs Easily
- Output Webpages
I will be discussing the rationale behind each directory and show how it can be used together with your codes.
components directory will contain all of the page controllers, modules and API controllers. The directories under the
components are the
screens wherein each item serves its purpose.
apidirectory 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.
modulesdirectory will contain atomic services. These services will be consumed by the different API and page controllers that will render the data for consumption.
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 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 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.
assetsdirectory 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 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.
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.
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.
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.