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
|
- WebSockets via SocketIO pour les communications en temps réel
|
||||||
- Authentification via JWT pour sécuriser les échanges
|
- 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
|
- 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
|
- CI/CD via GitHub Actions pour l'intégration et le déploiement continus
|
||||||
- Infrastructure scalable pour gérer les pics de charge
|
- Infrastructure scalable pour gérer les pics de charge
|
||||||
|
Loading…
x
Reference in New Issue
Block a user