Folder Structure

1. Layer-based Structure (by type of file)

Use for small projects or learning

This is the most common and beginner-friendly structure. Files are grouped by their role: controllers, models, routes, services, utils, config.

Example:

Copy

project-root/
├─ controllers/
│  ├─ userController.js
│  └─ authController.js
├─ models/
│  ├─ user.js
│  └─ order.js
├─ routes/
│  ├─ userRoutes.js
│  └─ authRoutes.js
├─ services/
│  ├─ emailService.js
│  └─ paymentService.js
├─ utils/
│  └─ logger.js
├─ config/
│  └─ dbConfig.js
├─ constants/
│  ├─ roles.js
│  └─ paymentStatus.js
├─ app.js
└─ package.json

Advantages:

• Easy to understand for beginners.

• Clear separation of responsibilities.

• Standard practice in many tutorials and small/medium apps.

Disadvantages:

• In large projects, you may jump between multiple folders for one feature (controller in one folder, model in another, service in another).

• Harder to track all code related to a single feature.

---

2. Feature-based Structure (by feature/module)

Use for large modular projects.

Instead of grouping by file type, you group by business feature. Each feature has its own controller, model, route, and service.

Example:

Copy

project-root/
├─ user/
│  ├─ userController.js
│  ├─ userModel.js
│  ├─ userRoutes.js
│  └─ userService.js
├─ auth/
│  ├─ authController.js
│  ├─ authModel.js
│  ├─ authRoutes.js
│  └─ authService.js
├─ product/
│  ├─ productController.js
│  ├─ productModel.js
│  ├─ productRoutes.js
│  └─ productService.js
├─ utils/
│  └─ logger.js
├─ config/
│  └─ dbConfig.js
├─ app.js
└─ package.json

Advantages:

• Everything related to one feature is in one folder.

• Makes it easier to scale and manage large projects.

• Features can be worked on independently by different teams.

• Easier to test or remove one feature without breaking others.

Disadvantages:

• More duplication (similar folder structures repeated in each feature).

• Might feel overwhelming for beginners.

---

3. Hybrid Structure (recommended for real-world apps)

You can combine both approaches:

• Common/shared files go into layer-based folders (utils/, config/).

• Business logic is organized by feature.

Example:

Copy

project-root/
├─ features/
│  ├─ user/
│  │  ├─ userController.js
│  │  ├─ userModel.js
│  │  ├─ userRoutes.js
│  │  └─ userService.js
│  ├─ auth/
│  │  ├─ authController.js
│  │  ├─ authModel.js
│  │  ├─ authRoutes.js
│  │  └─ authService.js
│  └─ product/
│     ├─ productController.js
│     ├─ productModel.js
│     ├─ productRoutes.js
│     └─ productService.js
├─ utils/
│  └─ logger.js
├─ config/
│  ├─ dbConfig.js
│  └─ serverConfig.js
├─ middlewares/
│  ├─ authMiddleware.js
│  └─ errorHandler.js
├─ tests/
│  └─ user.test.js
├─ app.js
└─ package.json

Advantages:

• Best of both worlds.

• Shared logic and configs are centralized.

• Features stay independent.

• Easy to scale from small app → enterprise-level app.

Disadvantages:

• Requires discipline to decide what belongs in features/ and what belongs in global folders.

---

Tips for All Structures

1. Keep names meaningful and consistent (userRoutes.js instead of uR.js).

2. Use plural for folders (controllers/, models/, services/).

3. Avoid deep nesting (e.g., /controllers/api/v1/admin/user/ gets messy).

4. Separate test files into a tests/ folder or place them next to the code with .test.js.

5. Environment configs (.env) should never go inside feature folders—always in root.