docs: add system architecture interaction flow diagram
This commit is contained in:
parent
765a5e35ae
commit
b0e1c062b4
65
cdc.md
65
cdc.md
@ -114,7 +114,70 @@ L'application suivra une architecture monorepo avec séparation claire entre le
|
||||
- WebSockets via SocketIO pour les communications en temps réel
|
||||
- Authentification via JWT pour sécuriser les échanges
|
||||
|
||||
#### 2.2.3 Déploiement
|
||||
#### 2.2.3 Architecture et Flux d'Interactions
|
||||
Le diagramme ci-dessous illustre les interactions entre les différents composants du système:
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph Client["Client (Navigateur)"]
|
||||
FE["Frontend (NextJS)"]
|
||||
end
|
||||
|
||||
subgraph Server["Serveur"]
|
||||
BE["Backend (NestJS)"]
|
||||
WS["WebSocket (SocketIO)"]
|
||||
end
|
||||
|
||||
subgraph Storage["Stockage"]
|
||||
DB[(PostgreSQL)]
|
||||
S3[("Stockage S3\n(Fichiers)")]
|
||||
end
|
||||
|
||||
FE <-->|"1. Requêtes HTTP/API REST"| BE
|
||||
FE <-->|"2. Communication temps réel"| WS
|
||||
BE <-->|"3. Requêtes SQL via DrizzleORM"| DB
|
||||
BE <-->|"4. Stockage/Récupération de fichiers"| S3
|
||||
BE <-->|"5. Événements temps réel"| WS
|
||||
|
||||
classDef client fill:#f9f,stroke:#333,stroke-width:2px
|
||||
classDef server fill:#bbf,stroke:#333,stroke-width:2px
|
||||
classDef storage fill:#bfb,stroke:#333,stroke-width:2px
|
||||
|
||||
class Client client
|
||||
class Server server
|
||||
class Storage storage
|
||||
```
|
||||
|
||||
Ce diagramme montre les principaux flux d'interactions:
|
||||
|
||||
1. **Frontend ↔ Backend**: Communication via API REST pour les opérations CRUD standard
|
||||
- Requêtes HTTP pour la création, lecture, mise à jour et suppression de données
|
||||
- Authentification via JWT pour sécuriser les échanges
|
||||
- Validation des données côté client et serveur
|
||||
|
||||
2. **Frontend ↔ WebSocket**: Communication en temps réel
|
||||
- Notifications instantanées
|
||||
- Mises à jour en direct des groupes
|
||||
- Collaboration entre utilisateurs
|
||||
|
||||
3. **Backend ↔ Base de données**: Persistance des données
|
||||
- Requêtes SQL optimisées via DrizzleORM
|
||||
- Transactions pour garantir l'intégrité des données
|
||||
- Utilisation d'index pour des performances optimales
|
||||
|
||||
4. **Backend ↔ Stockage S3**: Gestion des fichiers
|
||||
- Stockage des avatars utilisateurs
|
||||
- Sauvegarde des exports de données
|
||||
- Gestion des pièces jointes
|
||||
|
||||
5. **Backend ↔ WebSocket**: Gestion des événements
|
||||
- Diffusion des mises à jour aux clients connectés
|
||||
- Gestion des salles pour les projets collaboratifs
|
||||
- Notification des changements en temps réel
|
||||
|
||||
Cette architecture permet une séparation claire des responsabilités tout en offrant une expérience utilisateur fluide et réactive.
|
||||
|
||||
#### 2.2.4 Déploiement
|
||||
- Conteneurisation avec Docker pour assurer la cohérence entre les environnements
|
||||
- CI/CD via GitHub Actions pour l'intégration et le déploiement continus
|
||||
- Infrastructure scalable pour gérer les pics de charge
|
||||
|
Loading…
x
Reference in New Issue
Block a user