The Most Efficient Architecture for Your Express.js Project: A Story of Lessons Learned

Hi and welcome to my first article here! Today I will tell you my personal story-learning about Architecture structure building pain :)

It all started three years ago, when I embarked on my journey to build a robust and maintainable Express.js application. At first, my codebase was chaotic: I had controllers, services, and even business logic scattered all over the place.

How it was before:

But after countless trials, I found a folder structure that finally brought order to the chaos:

Within the app folder, each subfolder addresses a unique part of the system:

1. Controllers handle requests and responses, living on a thin layer that delegates the heavy work elsewhere.

How controllers folder looks like (modules)

2. Routes define the actual endpoints, grouping them by domain or feature for clarity.

How routes folder looks like (we have folder pulse, but it’s only because of some experiments there)

3. Services contain the core business logic, making sure controllers remain uncluttered.

1. Helpers store reusable functions to avoid code duplication.
2. Models map to database structures, helping maintain a consistent approach to data.
3. DTOs (Data Transfer Objects) ensure data integrity as it travels between layers.
4. Scripts automate tasks like database seeding or migrations, keeping these routines organized.
5. Types centralize all TypeScript definitions for reusability and reliability.
6. Utils hold utility classes or specialized functionality that doesn’t neatly fit in other folders.

Meanwhile, the tests folder stands separate to keep all testing logic away from production code. Inside it, you might find a unit subfolder for testing small, isolated pieces of functionality, and possibly an integration subfolder to test how different modules work together.

In the early days, I lumped tests in the same directories as my controllers and services, but separating them helped clarify what belonged where.

I recall an example from one of my first big refactors: I moved a messy login endpoint’s logic out of the controller into a dedicated AuthService. Suddenly, the controller’s code shrank to a few lines, and debugging became a breeze and in addition, I created a LoginDTO to shape incoming login requests, ensuring my service received the right data. This not only improved readability but also let TypeScript catch errors early, saving me from embarrassing production bugs.

In the end, it wasn’t just about looking tidy — it was about reducing technical debt and making life easier for everyone involved. When we brought on new developers, the established folder structure acted like a map, guiding them through controllers, routes, and services without confusion. They understood the flow of data from a request hitting a route, traveling through a controller, getting processed by a service, and using a model to interact with the database.

With each new feature, the separation of concerns made code reviews faster and allowed for modular development. This architecture also let us reuse code across domains in helpers, utilities, and DTOs, rather than rewriting the same functions over and over. Before long, we witnessed fewer bugs, simpler merges, and quicker turnarounds for new features.

Reflecting on this journey, I can confidently say that a well-structured app folder—paired with a dedicated tests folder—forms the backbone of a clean, scalable Express.js project. Each time I start a new application, I begin by creating these folders, preparing them for controllers, routes, services, helpers, models, DTOs, scripts, types, and utils. Then, I set up my tests, ensuring each area of the codebase is thoroughly validated.

This folder structure, coupled with TypeScript’s static typing, fosters a sense of order and reliability in code. It keeps everyone on the team aligned, drastically reduces debugging headaches, and allows the application to grow gracefully. That’s the story of how I found an architecture that not only looks neat from the outside but also gives me the confidence to tackle any feature or scale to new heights. And if you’re on a similar path

I hope these lessons can guide you to a neater, more maintainable Express.js future.