# Frontières entre code moderne et legacy

## Pourquoi cette page existe

Le projet Web combine une architecture NestJS/Angular moderne avec une couche plus ancienne sous `src/node.js/server/`. Les deux sont encore actives. Comprendre cette frontière évite de réécrire une fonctionnalité déjà existante ou de modifier la mauvaise couche.

## Carte simplifiée

```mermaid
flowchart LR
    ANG[Angular] --> NEST[NestJS moderne]

    NEST --> CTRL[Controllers]
    CTRL --> SVC[Services TypeScript]
    SVC --> ORM[TypeORM / MySQL]
    SVC --> REDIS[RedisService]

    SVC --> LEGACY[src/node.js/server]
    LEGACY --> BC[BrainCloud]
    LEGACY --> REDIS
    LEGACY --> ADMIN[Admin Server Express]
    LEGACY --> AI[Serveur IA]

```

## Couche moderne

La majorité du nouveau code backend devrait naturellement passer par :

- `app.controller.ts` pour les endpoints;
- `service/*.service.ts` pour la logique métier;
- `entities/` et TypeORM pour MySQL;
- `guards/` pour l’autorisation;
- `gateway/` pour le temps réel.

## Couche historique / auxiliaire

`src/node.js/server/` contient encore plusieurs responsabilités importantes :

- `server.js` : fonctions historiques de jeu, présence, rankings, images, etc.;
- `backend_braincloud.js` : intégration BrainCloud;
- `admin_server.js` : serveur Express admin séparé;
- `constantsVariable.js` : configuration globale et constantes;
- `ai/` : serveur IA et providers.

## Quand utiliser quelle couche

```mermaid
flowchart TD
    NEW[Nouveau changement backend] --> EXIST{Fonction existante déjà dans node.js/server ?}
    EXIST -- Oui --> CONTRACT{Peut-on garder le contrat et l'encapsuler ?}
    CONTRACT -- Oui --> WRAP[Appeler depuis un service NestJS]
    CONTRACT -- Non --> MIGRATE[Planifier migration explicite]
    EXIST -- Non --> MODERN[Implémenter dans Controller + Service NestJS]

    MODERN --> DATA{Persistance ?}
    DATA -- SQL --> ORM[TypeORM]
    DATA -- Runtime --> REDIS[RedisService]

```

## Règle générale

Pour une nouvelle fonctionnalité, privilégier NestJS et les services TypeScript. Ne déplacer du code historique que lorsqu’il y a une raison claire : simplification, suppression d’une dépendance legacy ou correction d’un problème architectural. Une migration opportuniste au milieu d’une feature augmente le risque.

## Signaux qu’on touche du legacy

- appel direct à `backend_braincloud.js`;
- fonction exportée depuis `server.js`;
- utilisation du serveur Express admin;
- globals comme `NodeJsServer`, `NodeJsUtils` ou `NodeJsBackendBraincloud` initialisés dans `database.providers.ts`.

## Avant de refactorer

- Identifier tous les appels entrants vers la fonction legacy.
- Vérifier les effets Redis, BrainCloud et fichiers locaux.
- Conserver le contrat API existant si possible.
- Séparer migration et changement fonctionnel lorsqu’ils sont suffisamment gros.

## Frontière des notifications après refactoring

Les anciennes fonctions d’inbox/notification ont été retirées de `server.js`. La responsabilité appartient à `NotificationService` (stockage Redis, événement du compte et push) et à `GameNotificationService` (autorisation BrainCloud et résolution profil jeu → compte). Ne pas réintroduire une seconde inbox dans la couche historique. `AccountGateway` diffuse les notifications; `SupportGateway` conserve les conversations et tickets.