La structure et l'architecture d'un projet NestJS (main.ts, app.module.ts…)

Vue d'ensemble

api-formation/
├── dist/                    ← code JavaScript compilé (généré, non versionné)
├── node_modules/            ← dépendances (générées, non versionnées)
├── src/                     ← VOTRE CODE
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   └── main.ts
├── test/                    ← tests end-to-end
│   ├── app.e2e-spec.ts
│   └── jest-e2e.json
├── .gitignore
├── .prettierrc
├── nest-cli.json
├── package.json
├── package-lock.json
├── README.md
├── tsconfig.build.json
└── tsconfig.json

On travaille presque exclusivement dans src/. Les autres fichiers configurent le projet (leçon 3.4).

main.ts : le point d'entrée

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

C'est le premier fichier exécuté : il crée l'application à partir du module racine et démarre le serveur. Il est détaillé à la leçon 3.3.

app.module.ts : le module racine

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],                    // autres modules utilisés
  controllers: [AppController],   // contrôleurs de ce module
  providers: [AppService],        // services injectables
})
export class AppModule {}

Le décorateur @Module décrit l'organisation : NestJS lit ces métadonnées pour savoir quelles classes créer et comment les relier. Chaque nouvelle fonctionnalité (stagiaires, groupes…) aura son propre module, ajouté dans imports.

app.controller.ts : les routes

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()                       // préfixe de route : aucun → '/'
export class AppController {
  constructor(private readonly appService: AppService) {}  // injection

  @Get()                            // GET /
  getHello(): string {
    return this.appService.getHello();
  }
}

Le contrôleur reçoit les requêtes HTTP. Il ne contient pas de logique : il délègue au service, qu'il reçoit par son constructeur.

app.service.ts : la logique

import { Injectable } from '@nestjs/common';

@Injectable()                       // peut être injecté ailleurs
export class AppService {
  getHello(): string {
    return 'Hello World!';
  }
}

La requête GET / arrive au contrôleur, qui appelle le service ; la valeur renvoyée devient la réponse HTTP.

Les fichiers de test

• *.spec.ts (dans src/) : tests unitaires, placés à côté du fichier testé. app.controller.spec.ts vérifie que getHello() renvoie « Hello World! ».
• test/app.e2e-spec.ts: test end-to-end, qui démarre l'application et envoie une vraie requête GET /.

Les tests sont étudiés au chapitre 17 ; en attendant, ne supprimez pas ces fichiers et lancez npm test de temps en temps.

Les dépendances principales

Organiser un vrai projet : par fonctionnalités

On ne range pas tous les contrôleurs dans un dossier et tous les services dans un autre. On crée un dossier par fonctionnalité, qui contient tout ce qui la concerne :

src/
├── app.module.ts
├── main.ts
├── stagiaires/
│   ├── dto/
│   ├── entities/
│   ├── stagiaires.controller.ts
│   ├── stagiaires.module.ts
│   └── stagiaires.service.ts
├── groupes/
│   └── …
└── common/          ← éléments partagés (filtres, guards, décorateurs…)

Activités

// app.service.ts
getVersion() {
  return { application: 'api-formation', version: '0.0.1' };
}

// app.controller.ts
@Get('version')
getVersion() {
  return this.appService.getVersion();
}