2022-01-10
1363
#node
Geshan Manandhar
85866
Jan 10, 2022 ⋅ 4 min read

Organizing your Express.js project structure for better productivity

Geshan Manandhar Geshan is a seasoned software engineer with more than a decade of software engineering experience. He has a keen interest in REST architecture, microservices, and cloud computing. He also blogs at geshan.com.np.

Recent posts:

Where AI-assisted coding accelerates development — and where it doesn’t

Where AI-assisted coding accelerates development — and where it doesn’t

John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.

John Reilly
Oct 22, 2025 ⋅ 12 min read
Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Learn how to effectively debug with Chrome DevTools MCP server, which provides AI agents access to Chrome DevTools directly inside your favorite code editor.

Emmanuel John
Oct 21, 2025 ⋅ 6 min read
Goodbye, useState? Smarter state modeling for modern React apps

Goodbye, useState? Smarter state modeling for modern React apps

Ever opened a React file and found a graveyard of useState hooks? The problem isn’t React; it’s how we model state. Here’s how to do it smarter.

Oscar Jite-Orimiono
Oct 21, 2025 ⋅ 9 min read

Why third-party integrations break in React 19 — And how to future-proof them

React 19 breaks old third-party integrations. Learn why concurrent rendering exposes brittle SDKs and how to rebuild them with resilient modern patterns.

Peter Aideloje
Oct 20, 2025 ⋅ 4 min read
View all posts

8 Replies to "Organizing your Express.js project structure for better productivity"

  1. This folder structure is only suitable for small projects. It is good to me tion that component based decomposition works better for larger applications.

    1. Exactly, I don’t understand why they keep promoting this structure, it seems that it was just a copy of another post.
      This may seem appealing for small projects, when they grow, it becomes very difficult to maintain a feature that has files scattered in random places in the project. ( since not all functionality will have Repository, service etc ).

      He is a good discussion about it: https://softwareengineering.stackexchange.com/questions/338597/folder-by-type-or-folder-by-feature

  2. What would be the difference between `services` and `controllers` ? How do you decide which logic you want to place in what folder ?

    1. Putting big piece of code inside controller may be not the best idea when you need to manage a lot of them. Also the logic can be reusable. So exporting that logic into functions may work for larger projects. You can store that functions inside services. I’m not sure if this is what author meant, but after working on couple projects – it’s quite common solution.

    2. Service layers would contain any to most of the business logic. Controllers on the other hand are meant to only handle requests from and to the view (or presentation layer), and to handle model retrieval from and to the service layer. Thinking on an MVC design. I suggest you to take my comment and prompt it to an AI for further description.

  3. Controllers here are written as bare functions,
    How could we apply different middlewares to each controllers depending on need?

    This is useful when validating data fields that are only present in some of the controllers. Otherwise, we would need to explicitly declare an error return statement, which is prone to error.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now