senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/archive/root-md/REPORT_ARCHITECTURE.md
senke 43af35fd93 chore(audit 2.2, 2.3): nettoyer .md et .json à la racine 
- Archiver 131 .md dans docs/archive/root-md/
- Archiver 22 .json dans docs/archive/root-json/
- Conserver 7 .md utiles (README, CONTRIBUTING, CHANGELOG, etc.)
- Conserver package.json, package-lock.json, turbo.json
- Ajouter README d'index dans chaque archive
2026-02-15 14:35:08 +01:00

2.5 KiB
Raw Blame History

🏗️ REPORT_ARCHITECTURE.md - Cartographie Technique

1. Architecture des Services

🟢 Service: Backend API (veza-backend-api)

  • Rôle: Cœur de métier, gestion utilisateurs, metadata, catalogue.
  • Langage: Go (Golang).
  • Framework: Gin Gonic.
  • Data: GORM + PostgreSQL.
  • Observation: Gère la logique métier lourde. A subi une refonte massive vers UUID.

🔵 Service: Chat Server (veza-chat-server)

  • Rôle: Messagerie temps-réel, présence, WebSockets.
  • Langage: Rust.
  • Framework: Axum + Tokio.
  • Data: SQLx + PostgreSQL + Redis (Cache).
  • Dépendances: Très riche (jsonwebtoken, argon2, tonic gRPC).
  • Observation: Architecture très propre, moderne, orientée performance.

🟣 Service: Stream Server (veza-stream-server)

  • Rôle: Streaming audio haute performance, transcodage.
  • Langage: Rust.
  • Framework: Axum + Symphonia (Audio).
  • Observation: Utilise rayon pour le parallélisme. Service critique pour l'expérience utilisateur.

2. Architecture Frontend (Le Conflit)

🅰️ Apps/Web (apps/web) - LA CIBLE

  • Stack: React 18, Vite, TailwindCSS, Zustand, TanStack Query, Radix UI.
  • Qualité: Très haute. Utilise les standards modernes (hooks, composants atomiques, shadcn/ui like).
  • Rôle: Web App principale.

🅱️ Veza Desktop (veza-desktop) - LEGACY?

  • Stack: Electron, React (plus ancien), Redux (vs Zustand sur web).
  • Problème: Semble être une implémentation parallèle et non un wrapper de apps/web.
  • Risque: Double maintenance des features.

3. Données & Infrastructure

Base de Données (PostgreSQL)

  • Architecture distribuée ou monolithique logique ?
  • Problème: veza-backend-api et veza-chat-server ont chacun leur dossier migrations/.
  • Risque: Désynchronisation des schémas (ex: table users définie à deux endroits ?).

Communication Inter-Services

  • Preuves de gRPC (tonic) dans les fichiers Cargo.
  • Preuves de RabbitMQ (lapin) mentionné.

4. Diagramme de Flux (Simplifié)

graph TD
    Client[Clients (Web/Desktop/Mobile)] --> HAProxy[HAProxy / Load Balancer]
    HAProxy --> Go[Go Backend API]
    HAProxy --> Chat[Rust Chat Server]
    HAProxy --> Stream[Rust Stream Server]
    
    Go --> DB[(PostgreSQL Core)]
    Chat --> DB
    Chat --> Redis[(Redis Cache)]
    Stream --> FS[File System / S3]
    
    Go -.-> RabbitMQ((RabbitMQ Event Bus))
    Chat -.-> RabbitMQ