Project Structure

Our project follows a well-organized and modular structure that promotes maintainability, scalability, and testability. In this section, we will outline the key aspects of the project structure and explain the purpose of each directory.

Overview

The project structure is organized as follows:

project/
├── dist/
├── docs/
│   ├── c4
│   │   └── ...
│   └── erd
│   │   └── ...
├── node_modules/
├── src/
│   ├── entrypoints/
│   │   └── ...
│   ├── modules/
│   │   └── ...
│   ├── sql/
│   │   └── ...
│   ├── utils/
│   │   └── ...
│   ├── app.module.ts
├── test/
│   ├── expect/
│   │   └── ...
│   ├── seeders/
│   │   └── ...
│   ├── setup/
│   │   └── ...
│   ├── utils/
│   │   └── ...
├── .dockerignore
├── .env
├── .env.test
├── .gitignore
├── docker-compose.yaml
├── Dockerfile
├── eslint.config.js
├── nest-cli.json
├── package.json
├── pnpm-lock.yaml
├── README.md
└── tsconfig.json

dist

The dist directory contains the compiled JavaScript files generated from the TypeScript source code. These files are used for deployment and production builds.

docs

The docs directory houses the technical documentation of the application. Like a C4 and ERD model.

node_modules

The node_modules directory contains the dependencies required by the project. These dependencies are installed and managed using a package manager, such as npm or pnpm.

src

The src directory is at the heart of the application, containing the source code and various modules that make up the project. It follows a modular and scalable approach, allowing for easy maintenance and extension of the codebase.

entrypoints

The entrypoints directory is responsible for defining the application's main entry points, such as the API server and worker processes. These entry points are used to start the application and connect it to the required services.

modules

The Modules directory holds the individual application modules, which are organized into separate subdirectories based on their functionality. Each component typically includes controllers, commands, middlewares, models, repositories, routers, services, tests, and transformers. This structure encourages a clear separation of concerns, ensuring that each part of the component is responsible for a specific aspect of its functionality.

sql

In the sql directory, you can find migrations and datasource files for the database.

utils

We try to avoid using this directory, but if we need to store some utility functions, we will put them here.

test

The test directory holds general code for testing the application like additional expect functions, an abstract seeder class and helper functions.

Configuration Files and Environment Variables

The .env and .env.test files contain environment-specific configurations and secrets, such as database connection strings and API keys. The eslint.config.js file configures the linting rules for the project, while the tsconfig.json file sets up the TypeScript compiler options.

CI/CD, Docker, and Testing

The .githyb directory configures the continuous integration and deployment pipeline for the project. The docker-compose.yaml and Dockerfile files are used to create and manage Docker containers for the application.

Package Management and Documentation

The package.json file manages the project's dependencies, scripts, and metadata. The pnpm-lock.yaml file locks the dependency versions to ensure consistent installations across environments. The README.md file serves as an introduction and documentation for the project.

The project structure follows best practices for backend development, providing a clean separation of concerns and ensuring a maintainable, scalable, and reliable codebase.