Aller au contenu principal

Interne — stack, modules et workflow

Stack et modules utilisés

  • Backend: NestJS (TypeScript)
    • Modules: produits, fournisseurs, entrepots, magasins (modules de démo intercom, foods retirés)
    • Swagger activé globalement via main.ts (/api/swagger)
    • Scheduling activé (@nestjs/schedule)
    • Email: @nestjs-modules/mailer + Handlebars (backend/email_templates)
  • Base de données: Postgres + drizzle-orm
    • Schéma: backend/src/db/schema.ts
    • Service: DrizzleService (CRUD avec soft-delete et timestamps)
    • Migrations: backend/drizzle/* (générées via drizzle-kit)
    • Soft-delete: Le champ deletedAt est géré en interne par DrizzleService mais n'est jamais exposé dans les réponses API grâce à une sélection automatique des champs dans la méthode select()
  • Frontend: React + Vite (TypeScript), MUI
    • Pages de démo retirées: Foods, Intercom
    • Base API: VITE_API_HOST (Nginx sur :649 en dev)
  • Proxy dev: Nginx (reverse proxy https://referentiel.staging.ubsi.fr → Vite 5173 + Nest 3000)
  • Optionnel: RabbitMQ (provisionné via docker-compose, code commenté)

Conventions backend

  • Préfixe des controllers: api/... (ex: api/publique/produits)
  • DTOs annotés avec @ApiProperty pour Swagger + class-validator
  • DrizzleService:
  • Les tables doivent inclure: id, createdAt, updatedAt, deletedAt

Variables d’environnement (backend)

  • Obligatoires: NESTJS_PORT, DATABASE_URL
  • Optionnelles:
    • CORS_CONFIG_JSON (JSON string, défaut { "origin": "*" })
    • (Retiré) ORIGIN_APP_{APP} anciennement utilisé par Intercom (achat, bi, ecommerce, fidelite, gestion, logistique, paiement, promotion, referentiel, sav)
    • CURRENT_COMMIT, CURRENT_CONFIG pour logs au boot

Scripts et dev workflow local

  • Infra: docker compose up -d (Postgres, RabbitMQ, Nginx)
  • Backend: cd backend && npm i && npm run start:dev (env: NESTJS_PORT=3000, DATABASE_URL)
  • Frontend: cd frontend && npm i && npm run dev -- --host (env: VITE_API_HOST=http://localhost:649)
  • DB: cd backend && npx drizzle-kit generate && npx drizzle-kit migrate

Tests

  • Unitaires: backend → npm run test
  • E2E: backend → npm run test:e2e
  • Dossiers de tests: backend/test/* + specs par module (*.controller.spec.ts, *.service.spec.ts)

Logging

  • Utiliser new Logger(ClassName) dans controllers/services
  • Logguer la route et l’ID concerné; debug pour payloads; warn pour cas attendus (404, validation) et error pour exceptions

Workflow GitLab

  1. Le PO crée une issue (épic/story/tâche) avec description claire, critères d’acceptation et label(s).
  2. Lorsqu’un dev démarre, il passe l'issue en « In Progress ».
  3. Le développeur crée une branche dédiée et une MR associée, avec :
  • une description contenant Closes #<issue>,
  • l’ajout du tech lead (a minima) comme reviewer,
  • un milestone défini,
  • et il s’assigne lui-même à la MR.
  1. Une review minimale est requise pour merger la MR (au moins 1 reviewer approuve).
  2. Attendre que toutes les pipelines liées à dev soient au vert avant de merger.
  3. Déploiements:
    • dev → préprod, puis préprod → prod effectués par le PO après vérification fonctionnelle.
    • Pas de review obligatoire pour les déploiements (même si recommandé).
    • Se référer à la doc globale DevOps pour le processus de release et versions.

Historique (Intercom & Foods)

Les modules de démonstration intercom (proxy/ping inter-apps) et foods (CRUD + email) ont été retirés du code afin d'épurer la base. Les schémas de données associés pouvant subsister dans l'historique de migrations ne sont pas ré-exposés côté API.