Intercalaire 3 : APPS & SERVICES

Généré le 4 Avril 2026 - Projet Talas

APIs & Modules Rust – Performances & Interop

Ce dossier contient les spécifications API de Talas (REST/gRPC), ainsi que les modules Rust haute performance pour le streaming audio, le traitement en ligne, et le rendu.

Objectifs :

• Créer une interopérabilité robuste entre les différents services.
• Offrir un moteur Rust performant pour les traitements audio.
• Structurer une API claire, documentée, et évolutive.

Contenu :

• API_Specs/ : OpenAPI, gRPC Protobuf, GraphQL schemas
• Rust_Engines/ : streaming, encodage, plugins
• Benchmarks/ : perfs sur FLAC, Opus, WebRTC

Ces modules peuvent être exposés comme services REST ou microservices via gRPC.

Référence Complète des Routes API Veza

Inventaire exhaustif de tous les endpoints REST et WebSocket. Source : veza-backend-api/internal/api/routes_*.go et veza-stream-server/src/routes/api.rs ~500+ endpoints au total.

Conventions

• Base URL : /api/v1
• Auth : JWT RS256 via cookie HTTP-only ou header Authorization: Bearer <token>
• CSRF : Token Redis obligatoire sur tous les POST/PUT/DELETE protégés
• Rate limiting : Global (1000 req/s), par IP (100 req/s), par endpoint (variable)
• Réponses : JSON, pagination par ?page=N&limit=N

Légende des badges

1. Authentification (/auth)

Fichier : routes_auth.go

Endpoints publics

Endpoints protégés

2. Utilisateurs (/users)

Fichier : routes_users.go

Endpoints publics

Endpoints protégés

3. Rôles (/roles)

Fichier : routes_users.go

4. Pistes audio (/tracks)

Fichier : routes_tracks.go

Endpoints publics

Endpoints HLS (publics)

Endpoints protégés

Commentaires

5. Playlists (/playlists)

Fichier : routes_playlists.go

6. Chat & Conversations (/chat, /conversations)

Fichier : router.go, routes_core.go

Chat

Conversations

7. Social (/social)

Fichier : routes_social.go

Endpoints publics

Endpoints protégés

8. Découverte (/discover)

Fichier : routes_discover.go

9. Recherche (/search)

Fichier : routes_search.go

Backend : Elasticsearch (fallback PostgreSQL full-text).

10. Feed (/feed)

Fichier : routes_feed.go

11. File d'attente (/queue)

Fichier : routes_queue.go

12. Marketplace (/marketplace, /sell, /commerce)

Fichier : routes_marketplace.go

Marketplace (publics)

Marketplace (protégés)

Vendeur (/sell)

Commerce (/commerce)

Support

13. Webhooks (/webhooks)

Fichier : routes_webhooks.go

14. Analytics (/analytics, /creator/analytics)

Fichier : routes_analytics.go

15. Modération (/admin/moderation, /reports, /strikes)

Fichier : routes_moderation.go

Admin

Utilisateur

16. Administration plateforme (/admin/platform)

Fichier : routes_admin_platform.go

17. Live streaming (/live)

Fichier : routes_live.go

18. Co-écoute (/co-listening)

Fichier : routes_co_listening.go

19. Inventaire / Équipement (/inventory, /users/:id/gear)

Fichier : routes_gear.go

20. Cloud personnel (/cloud)

Fichier : routes_cloud.go

21. Abonnements (/subscriptions)

Fichier : routes_subscription.go

22. Distribution (/distributions)

Fichier : routes_distribution.go

23. Éducation (/courses, /enrollments, /lessons, /certificates)

Fichier : routes_education.go

Endpoints publics

Endpoints protégés

24. Tags & Suggestions (/tags)

Fichier : routes_tag.go

25. Développeur (/developer)

Fichier : routes_developer.go

26. Sessions (/sessions)

Fichier : routes_core.go

27. Uploads (/uploads)

Fichier : routes_core.go

28. Notifications (/notifications)

Fichier : routes_core.go

29. Audit (/audit)

Fichier : routes_core.go

30. Santé & Métriques (publics)

Fichier : routes_core.go

31. Administration générale (/admin)

Fichier : routes_core.go

32. Routes internes (entre services)

Serveur Streaming Rust (Axum)

Voir [[SERVEUR_STREAMING_RUST]] pour le détail complet.

Pile de middlewares globaux (ordre d'exécution)

1. CORS — Validation des origines
2. Cache Headers — En-têtes CDN
3. Maintenance Mode — Retourne 503 sauf /health et /admin
4. Request Logger — Logs structurés
5. Prometheus Metrics — Compteurs/histogrammes
6. Sentry Recovery — Capture d'erreurs
7. Security Headers — HSTS, CSP, X-Content-Type-Options
8. CCPA Header — Sec-GPC
9. Audit Middleware — Auto-log POST/PUT/DELETE
10. API Monitoring — Suivi pannes/alertes
11. Error Handler — Stack traces en dev/DEBUG
12. Recovery — Récupération après panic
13. Request ID — UUID par requête
14. Global Timeout — Timeout global
15. DDoS Rate Limiting — 1000 req/s global, 100/s par IP
16. Rate Limiter — Général
17. Response Cache — Redis, TTL 5-15 min

Documents liés

• [[ARCHITECTURE_VEZA]] — Architecture globale
• [[SCHEMA_BASE_DE_DONNEES]] — Schéma PostgreSQL
• [[SERVEUR_STREAMING_RUST]] — Serveur Rust détaillé

Serveur Streaming Rust (veza-stream-server)

Architecture du serveur audio haute performance basé sur Axum. Source : veza-stream-server/src/

Vue d'ensemble

Le stream server est un service Rust autonome qui gère : - Streaming audio HLS adaptatif multi-bitrate - WebSocket temps réel pour la lecture synchronisée - Transcoding audio via FFmpeg (WAV → MP3, HLS) - Métriques Prometheus pour le monitoring

Il communique avec le backend Go via RabbitMQ (événements asynchrones) et des callbacks REST internes.

Stack technique

Structure des modules

veza-stream-server/src/
├── main.rs                      # Point d'entrée, initialisation Axum
├── routes/
│   └── api.rs                   # Définition de toutes les routes
├── streaming/
│   ├── websocket.rs             # Handler WebSocket avec protocole de sync
│   ├── hls.rs                   # Génération de playlists HLS
│   └── adaptive.rs              # Sélection adaptative du bitrate
├── transcoding/
│   └── mod.rs                   # Orchestration transcoding FFmpeg
├── codecs/
│   └── mod.rs                   # Wrappers FFmpeg
├── audio/
│   └── mod.rs                   # Utilitaires audio
├── middleware/
│   ├── logging.rs               # Logs structurés
│   ├── security.rs              # Headers de sécurité
│   └── rate_limit.rs            # Rate limiting par IP
├── auth/
│   └── mod.rs                   # Validation JWT
├── config/
│   └── mod.rs                   # Configuration depuis env
├── health/
│   └── mod.rs                   # Health checks
├── monitoring/
│   └── mod.rs                   # Métriques Prometheus
├── cache/
│   └── mod.rs                   # Cache mémoire playlists
└── database/
    └── mod.rs                   # Requêtes PostgreSQL

Routes

Santé & monitoring

Streaming audio

Transcoding

Protocole WebSocket

Le WebSocket (/ws?track_id=...) utilise un protocole personnalisé pour la lecture synchronisée.

Commandes client → serveur

Réponses serveur → client

Cycle de vie d'une connexion

Client                          Serveur
  │                                │
  │── WS Connect ─────────────────▶│
  │   (track_id, JWT en query)     │
  │                                │── Validation JWT
  │                                │── Chargement playlist HLS
  │◀── ready ──────────────────────│
  │   (duration, bitrates)         │
  │                                │
  │── play { position: 0 } ──────▶│
  │                                │── Sélection bitrate adaptatif
  │◀── chunk ──────────────────────│
  │◀── chunk ──────────────────────│
  │◀── chunk ──────────────────────│
  │                                │
  │── heartbeat ──────────────────▶│  (toutes les 30s)
  │                                │
  │── seek { position: 120 } ────▶│
  │◀── chunk ──────────────────────│
  │                                │
  │── pause ──────────────────────▶│
  │                                │
  │── WS Close ───────────────────▶│

Streaming HLS adaptatif

Le serveur génère et sert des playlists HLS multi-bitrate avec sélection adaptative.

Qualités disponibles

Le transcoding produit plusieurs qualités à partir du fichier source :

Fonctionnement

1. Upload : Le backend Go reçoit le fichier audio et le stocke sur S3
2. Événement : track.uploaded publié sur RabbitMQ
3. Transcoding : Le stream server consomme l'événement, transcode via FFmpeg
4. Stockage : Les segments HLS et playlists sont stockés sur S3
5. Callback : POST /internal/tracks/:id/stream-ready vers le backend
6. Lecture : Le client demande le master playlist, le serveur sert les segments

Structure des fichiers HLS sur S3

hls/{track_id}/
├── master.m3u8            # Master playlist (liste les qualités)
├── low/
│   ├── playlist.m3u8      # Playlist 64 kbps
│   ├── segment_000.ts     # Segments audio
│   ├── segment_001.ts
│   └── ...
├── medium/
│   ├── playlist.m3u8      # Playlist 128 kbps
│   └── ...
├── high/
│   ├── playlist.m3u8      # Playlist 256 kbps
│   └── ...
└── lossless/
    ├── playlist.m3u8
    └── ...

Pile de middlewares

Appliqués dans l'ordre à toutes les routes :

1. CORS — Restrictif par défaut, origines configurables
2. Timeout — 30 secondes par requête
3. Compression — gzip
4. Security Headers — X-Content-Type-Options, X-Frame-Options, etc.
5. Rate Limiting — Par IP
6. Request Logging — Logs JSON structurés

Configuration

pub struct Config {
    port: u16,                        // PORT (default: 18082)
    database_url: String,             // DATABASE_URL
    rabbit_mq: RabbitMQConfig,        // RABBITMQ_URL
    s3_bucket: String,                // S3_BUCKET
    s3_region: String,                // S3_REGION
    log_level: String,                // LOG_LEVEL
    allowed_origins: Vec<String>,     // ALLOWED_ORIGINS
}

Toute la configuration provient des variables d'environnement (voir [[CONFIGURATION_ENVIRONNEMENT]]).

Communication inter-services

Événements RabbitMQ consommés

Callbacks REST vers le backend Go

Header d'authentification : X-Stream-Secret

Dockerfiles

Documents liés

• [[ARCHITECTURE_VEZA]] — Architecture globale
• [[ROUTES_API]] — Référence complète des routes
• [[CONFIGURATION_ENVIRONNEMENT]] — Variables d'environnement

Architecture Technique Veza

Document de référence — architecture globale de la plateforme Veza. Source : code dans /home/senke/git/talas/veza/

Vue d'ensemble

Veza est une plateforme musicale communautaire composée de 3 services principaux communiquant via REST, WebSocket et RabbitMQ, le tout orchestré par Docker Compose.

┌─────────────────────────────────────────────────────────────┐
│                        FRONTEND                              │
│              React 18 · TypeScript · Tailwind                │
│              Vite · Zustand · TanStack Query                 │
│                    (apps/web/)                                │
└──────────┬──────────────┬───────────────┬────────────────────┘
           │ REST /api/v1 │ WS /chat/ws   │ WS /stream
           ▼              ▼               ▼
┌──────────────────┐ ┌────────────────────────────────────────┐
│  BACKEND API     │ │         STREAM SERVER                   │
│  Go · Gin · GORM │ │         Rust · Axum                     │
│  (veza-backend-  │ │         (veza-stream-server/)            │
│   api/)          │ │                                          │
│                  │ │  • Streaming audio (HLS adaptatif)       │
│  • 500+ endpoints│ │  • WebSocket temps réel                  │
│  • Auth JWT RS256│ │  • Transcoding FFmpeg                    │
│  • RBAC complet  │ │  • Métriques Prometheus                  │
│  • CSRF Redis    │ │                                          │
│  • Rate limiting │ └──────────────┬─────────────────────────┘
│  • Audit logging │                │
└──────┬───────────┘                │
       │                            │
       ▼                            ▼
┌──────────────────────────────────────────────────────────────┐
│                     INFRASTRUCTURE                            │
│                                                               │
│  PostgreSQL 16 (:15432)    Redis 7 (:16379)                   │
│  Elasticsearch (:19200)    RabbitMQ 3 (:15672)                │
│  MinIO S3 (:19000)         ClamAV 1.4 (:13310)               │
└──────────────────────────────────────────────────────────────┘

Structure du monorepo

veza/
├── apps/web/                    # Frontend React (SPA + PWA)
├── veza-backend-api/            # API REST Go (Gin + GORM)
├── veza-stream-server/          # Serveur streaming Rust (Axum)
├── veza-common/                 # Code partagé Go/Rust
├── veza-docs/                   # Documentation technique
├── veza-desktop/                # Wrapper Electron (charge apps/web)
├── docker-compose.yml           # Infra développement
├── docker-compose.prod.yml      # Infra production
├── docker-compose.dev.yml       # Services dev uniquement
├── .env.example                 # Template de configuration
├── Makefile                     # Commandes build & dev
└── k8s/                         # Manifests Kubernetes

Ports réseau (isolation pour éviter les conflits)

Stack technique détaillée

Backend API (Go)

• Framework : Gin
• ORM : GORM v1 (mapping uniquement, migrations en SQL pur)
• Auth : JWT RS256 (fallback HS256), OAuth 2.0, WebAuthn/Passkeys, MFA TOTP
• Sécurité : CSRF Redis, rate limiting multi-niveaux, ClamAV antivirus, audit logging
• Recherche : Elasticsearch (fallback PostgreSQL full-text)
• Stockage : MinIO S3 compatible
• Monitoring : Prometheus, Sentry
• Base : PostgreSQL 16 avec UUIDs, soft deletes

Stream Server (Rust)

• Framework : Axum (async)
• Audio : HLS adaptatif multi-bitrate, FFmpeg transcoding
• Temps réel : WebSocket avec protocole de synchronisation
• Résilience : Circuit breaker, rate limiting, health checks
• Messaging : RabbitMQ pour les jobs de transcoding asynchrones

Frontend (React)

• Build : Vite v7.1.5
• UI : Tailwind CSS v4, Radix UI
• État : Zustand (stores), TanStack Query (data fetching)
• Formulaires : React Hook Form + Zod (validation)
• Routage : React Router v6 (52+ routes)
• i18n : i18next (EN/FR/ES)
• Tests : Vitest, Storybook
• Desktop : Electron wrapper (même codebase)

Patterns architecturaux

1. Microservices avec communication asynchrone

• Backend API (Go) → logique métier
• Stream Server (Rust) → streaming audio haute performance
• RabbitMQ → distribution d'événements entre services

2. Event-driven architecture

Événements principaux via RabbitMQ : - user.created → notifications, indexation - track.uploaded → scan ClamAV → transcoding HLS → indexation Elasticsearch - payment.completed → mise à jour commande, notification vendeur

3. Sécurité en profondeur

• CSRF tokens (Redis-backed, obligatoire en production)
• JWT RS256 avec rotation de clés
• OAuth 2.0 avec chiffrement des tokens
• ClamAV pour scan antivirus des uploads
• Rate limiting : global (1000 req/s), par IP (100 req/s), par endpoint
• Verrouillage de compte après N tentatives échouées
• Audit logging automatique sur POST/PUT/DELETE
• Headers de sécurité (HSTS, CSP, X-Content-Type-Options)
• CCPA/RGPD : opt-out, export de données, suppression de compte

4. Observabilité

• Logs structurés (JSON en production, texte en dev)
• Métriques Prometheus (endpoints /metrics)
• Sentry pour le tracking d'erreurs
• Health checks (liveness /healthz, readiness /readyz)

Flux de données principaux

Inscription utilisateur

Frontend POST /api/v1/auth/register
  → Backend : validation Zod, hash bcrypt, création User en DB
  → Email de vérification envoyé
  → JWT retourné en cookie HTTP-only
  → Frontend redirige vers /verify-email

Upload de piste audio

Frontend POST /api/v1/tracks (multipart/form-data)
  → Backend : scan ClamAV → stockage S3 → parsing métadonnées FFmpeg
  → Création Track en DB (status: processing)
  → Publication événement track.uploaded sur RabbitMQ

Stream Server (écoute RabbitMQ)
  → Réception track.uploaded
  → Transcoding WAV → MP3 + HLS multi-bitrate
  → Upload segments sur S3
  → Publication transcoding.completed

Backend (écoute événement)
  → Mise à jour Track (status: completed, stream_manifest_url)
  → Indexation Elasticsearch
  → Notification utilisateur

Lecture audio streaming

Frontend WS /stream?track_id=xxx&position=0
  → Stream Server : validation JWT
  → Chargement playlist HLS depuis cache/S3
  → Sélection bitrate adaptatif selon réseau
  → Envoi chunks audio via WebSocket
  → Heartbeat toutes les 30s

Commandes de développement

# Stack complète (backend Docker, web local)
make dev

# Tous les services locaux avec hot reload
make dev-full

# Infrastructure seule (DB, Redis, RabbitMQ, MinIO)
docker-compose up -d

# Services individuels
make dev-web              # Frontend seul
make dev-backend-api      # Backend seul
make dev-stream-server    # Stream server seul

# Build production
make build

# Migrations base de données
cd veza-backend-api && go run ./cmd/migrate_tool/main.go up

Fichiers clés (chemins absolus)

Documents liés

• [[ROUTES_API]] — Référence complète des endpoints API
• [[SCHEMA_BASE_DE_DONNEES]] — Schéma PostgreSQL complet (60+ tables)
• [[SERVEUR_STREAMING_RUST]] — Architecture du serveur Rust Axum
• [[FRONTEND_REACT]] — Architecture frontend React
• [[CONFIGURATION_ENVIRONNEMENT]] — Variables d'environnement et Docker

Authentification & Core System

Ce dossier contient les composants de base partagés entre les applications Talas : gestion des utilisateurs, sécurité, sessions, permissions et configuration générale.

Objectifs :

• Centraliser la logique d’authentification (JWT, OAuth, SSO).
• Fournir des services partagés pour toutes les apps (profil, sessions, ACL).
• Préparer une architecture modulaire facilement extensible.

Contenu recommandé :

• auth_controller.go / users.rs (ou équivalents)
• middleware/ : validation de token, CORS, accès protégé
• schemas/ : modèles utilisateur, rôles, permissions
• utils/ : génération tokens, encodage, vérification
• tests/ : login/signup, forgot password, refresh

Ce module doit être le plus découpé possible pour pouvoir s’adapter à la croissance future.

Configuration & Environnement Veza

Variables d'environnement, Docker Compose, et paramètres de déploiement. Source : .env.example, docker-compose*.yml, Makefile

Variables d'environnement

Toutes les variables sont définies dans .env.example à la racine du monorepo.

Core

Base de données (PostgreSQL)

Redis

RabbitMQ

JWT & Sécurité

Stockage S3 (MinIO)

Streaming & Live

Elasticsearch

Antivirus

Paiements

Logs & Monitoring

Frontend

Docker Compose

Développement (docker-compose.yml)

Services d'infrastructure pour le développement local :

# Lancer l'infrastructure
docker-compose up -d

# Ou via Makefile
make infra

Production (docker-compose.prod.yml)

Mêmes services avec : - Volumes persistants pour les données - Limites de ressources (CPU, mémoire) - Health checks sur tous les services - Configuration logging centralisée - Isolation réseau entre services - Restart policy : unless-stopped

Dockerfiles des services applicatifs

Backend API (Go)

Stream Server (Rust)

Frontend (React)

Commandes Makefile

# Développement
make dev                    # Stack complète (backend Docker, web local)
make dev-full               # Tous les services locaux + hot reload
make dev-web                # Frontend seul
make dev-backend-api        # Backend seul
make dev-stream-server      # Stream server seul

# Infrastructure
make infra                  # docker-compose up -d

# Build
make build                  # Build tous les conteneurs

# Base de données
make migrate-up             # Appliquer les migrations
make migrate-down           # Rollback dernière migration

# Tests
make test                   # Tous les tests
make test-backend           # Tests backend Go
make test-frontend          # Tests frontend Vitest
make test-e2e               # Tests end-to-end

Nginx (reverse proxy frontend)

Fichier : apps/web/nginx.conf

Configuration du reverse proxy en production :

Client → Nginx (port 80/443)
           ├── /          → fichiers statiques (SPA)
           ├── /api/*     → Backend Go (port 8080)
           ├── /ws/*      → Chat WebSocket (port 8081)
           └── /stream/*  → Stream Server Rust (port 8082)

Fonctionnalités : - SPA fallback : Toutes les routes non-API renvoient index.html - Gzip : Compression activée - Cache : Headers pour assets statiques (JS, CSS, images) - Sécurité : X-Frame-Options, X-Content-Type-Options

Différences dev / staging / production

Documents liés

• [[ARCHITECTURE_VEZA]] — Architecture globale
• [[ROUTES_API]] — Endpoints API
• [[SCHEMA_BASE_DE_DONNEES]] — Schéma PostgreSQL
• [[SERVEUR_STREAMING_RUST]] — Serveur streaming
• [[FRONTEND_REACT]] — Architecture frontend

Groupes & Chat

Module de messagerie communautaire pour groupes d’utilisateurs : collaboration, entraide, salon projet.

Objectifs :

• Créer des espaces privés/publics de discussion.
• Gérer les rôles, notifications, permissions.
• Permettre l’upload de fichiers légers (images, samples).

Contenu recommandé :

• WebSocket ou SSE backend
• rooms/, messages/, users/
• permissions/ : modérateurs, membres
• Web UI intégrable (chat component)

Inspiré de Discord/Mattermost, mais minimaliste.

Talas Community – App Communautaire

Ce dossier regroupe les composants de l’application communautaire de Talas : partage, groupes, chat, échanges entre artistes.

Objectifs :

• Offrir une plateforme fluide pour les petits créateurs.
• Favoriser les échanges, l’entraide, la collaboration et la visibilité.
• Permettre des extensions type forum, salon, recherche collaborateur.

Sous-sections :

• Groupes_Chat/ : groupes privés/publics, messagerie
• Partage/ : fichiers audio, presets, projets
• Troc/ : plateforme de don, échange matériel ou services
• Formation/ : espace de diffusion tutoriels, guides, lives

Peut évoluer vers un écosystème type SoundCloud + Discord + Coursera artisanal.

Architecture Frontend Veza (React)

Application web SPA + PWA avec support desktop Electron. Source : apps/web/src/

Stack technique

Structure du projet

apps/web/src/
├── app/                   # Composant App + initialisation
├── components/            # Composants UI (36 sous-dossiers)
│   ├── admin/            # Panel admin
│   ├── auth/             # Guards + flows auth
│   ├── commerce/         # Marketplace, checkout
│   ├── dashboard/        # Widgets dashboard
│   ├── feedback/         # Toasts, notifications
│   ├── layout/           # Sidebar, Header, MainLayout
│   ├── marketplace/      # Affichage produits, panier
│   ├── modals/           # Dialogues modaux
│   ├── player/           # Lecteur audio
│   ├── search/           # Recherche, filtres
│   ├── social/           # Likes, follows
│   ├── upload/           # Upload de fichiers
│   └── ui/               # Composants de base (19 sous-dossiers)
├── features/              # Modules fonctionnels (38 sous-dossiers)
│   ├── admin/            # Fonctionnalité admin
│   ├── analytics/        # Stats, graphiques
│   ├── auth/             # Flows d'authentification
│   ├── chat/             # Chat temps réel
│   ├── commerce/         # Logique marketplace
│   ├── developer/        # Outils développeur
│   ├── library/          # Bibliothèque musicale
│   ├── live/             # Streaming live
│   ├── marketplace/      # Marketplace
│   ├── notifications/    # Notifications
│   ├── playlists/        # Gestion playlists
│   ├── player/           # Logique lecteur audio
│   ├── profile/          # Profil utilisateur
│   ├── settings/         # Paramètres
│   ├── social/           # Social
│   ├── streaming/        # Streaming audio
│   └── tracks/           # Gestion pistes
├── hooks/                 # Hooks React custom (46 fichiers)
├── router/                # Configuration routage
│   ├── routeConfig.tsx   # Définition des routes
│   ├── AppRouter.tsx     # Wrapper routeur
│   ├── ProtectedRoute.tsx # Guard authentification
│   └── PublicRoute.tsx   # Wrapper pages publiques
├── services/              # Clients API & logique métier
│   ├── api/              # Couche API REST
│   ├── websocket/        # Handlers WebSocket
│   └── storage/          # Storage local/session
├── stores/                # Stores Zustand
├── types/                 # Types TypeScript (9 fichiers)
├── utils/                 # Utilitaires (52 fichiers)
├── schemas/               # Schémas Zod (validation)
├── config/                # Configuration (env, URLs API)
├── context/               # Providers React Context
├── lib/                   # Intégrations tierces
│   ├── i18n.ts           # Configuration i18next
│   └── sentry.ts         # Sentry error tracking
├── locales/               # Traductions i18n
├── styles/                # Styles globaux
└── __tests__/             # Tests

Routes de l'application

Routes publiques (sans authentification)

Routes protégées (authentification requise)

Gestion d'état (Zustand)

Stores principaux

// UI State (stores/ui.ts)
{
  sidebarOpen: boolean,
  darkMode: boolean,
  activeModal: string | null,
}

// Library State (stores/library.ts)
{
  favorites: Track[],
  recentlyPlayed: Track[],
  playlists: Playlist[],
}

// Cart State (stores/cartStore.ts)
{
  items: CartItem[],
  total: number,
}

// Rate Limit State (stores/rateLimit.ts)
{
  remaining: number,
  resetTime: Date,
}

Services API (services/api/)

Hooks personnalisés (hooks/)

46 hooks au total pour encapsuler la logique métier.

Configuration

// config/env.ts
export const env = {
  API_URL: import.meta.env.VITE_API_URL || '/api/v1',
  FRONTEND_URL: 'http://localhost:5173',
  USE_MSW: import.meta.env.VITE_USE_MSW === 'true',
  STORYBOOK: import.meta.env.VITE_STORYBOOK === 'true',
  SENTRY_DSN: import.meta.env.VITE_SENTRY_DSN,
}

Variables d'environnement frontend

Internationalisation (i18n)

• Bibliothèque : i18next
• Langues : Anglais (EN), Français (FR), Espagnol (ES)
• Fichiers : src/locales/
• Détection : Langue du navigateur automatique
• Persistance : localStorage

Scripts de développement

# Développement avec hot reload
npm run dev                 # ou : make dev-web

# Développement avec API mockée (MSW)
npm run dev:mocks

# Build production
npm run build

# Tests
npm run test               # Vitest
npm run test:e2e           # E2E (au root du repo)

# Qualité
npm run lint               # ESLint
npm run typecheck           # TypeScript strict

# Storybook (catalogue composants)
npm run storybook          # Port 6006
npm run build-storybook

Nginx (production)

En production, le frontend est servi par Nginx avec : - SPA routing : Toutes les routes renvoient vers index.html - Proxy /api → Backend Go (port 8080) - Proxy /ws → Chat WebSocket (port 8081) - Proxy /stream → Stream server (port 8082) - Compression gzip activée - Cache headers pour les assets statiques - Security headers : X-Frame-Options, X-Content-Type-Options

Configuration : apps/web/nginx.conf

Dockerfiles

Desktop (Electron)

Le dossier veza-desktop/ contient un wrapper Electron minimal qui charge apps/web. Pas d'application native séparée — le même code frontend est utilisé partout.

Statistiques

Documents liés

• [[ARCHITECTURE_VEZA]] — Architecture globale
• [[ROUTES_API]] — Endpoints API backend
• [[CONFIGURATION_ENVIRONNEMENT]] — Variables d'environnement

Talas Personal – Application Utilisateur

Ce dossier contient l’application personnelle Talas : gestion des produits achetés, plugins hébergés, fichiers audio, presets favoris.

Objectifs :

• Fournir à chaque artiste un “atelier personnel” connecté à Talas.
• Centraliser docs, garanties, ressources, historique d’usage.
• Intégrer des outils avancés (AudioGridder, presets, favoris cloud).

Sous-dossiers :

• AudioGridder_Client/ : serveur distant de plugins
• Cloud_Perso/ : fichiers audio, presets, snapshots
• Produits_Personnels/ : garanties, docs, historique

Tu peux l'étendre vers un "OS musical personnel" avec interopérabilité.

03_APPS_&_SERVICES – Développement Applicatif

Contient toutes les spécifications techniques de la plateforme Veza : architecture, API, schéma de données, streaming, frontend et configuration.

Le code source vit dans /home/senke/git/talas/veza/ — ce dossier ne contient que la documentation technique.

Documents de référence

Modules fonctionnels

• Auth_&_Core/ : inscription, login, sessions JWT RS256, RBAC, MFA, WebAuthn/Passkeys
• Shop/ : marketplace, panier, paiements Stripe Connect, KYC, royalties
• Community/ : social (feed, groupes, likes), chat temps réel, co-écoute
• Personal/ : cloud personnel, inventaire équipement, file d’attente
• APIs_&_Rust_Modules/ : routes API détaillées, serveur streaming Rust

Stack résumée

• Backend : Go (Gin, GORM) — 500+ endpoints, 68 modèles, 115 migrations SQL
• Streaming : Rust (Axum) — HLS adaptatif, WebSocket, transcoding FFmpeg
• Frontend : React 18, TypeScript, Tailwind v4, Zustand, TanStack Query
• Infra : PostgreSQL 16, Redis 7, RabbitMQ 3, Elasticsearch, MinIO S3, ClamAV

Connexions transversales

• [[04_INFRA_DEPLOIEMENT]] (CI/CD, conteneurisation, serveurs)
• [[05_EXPERIENCE_UTILISATEUR]] (interface + feedback UX)
• [[06_COMMUNAUTE_ECOSYSTEME]] (fonctions communautaires)

Schéma Base de Données Veza

Référence complète du schéma PostgreSQL — 60+ tables, UUIDs, soft deletes. Source : veza-backend-api/internal/models/ (68 fichiers Go) et migrations/ (115 fichiers SQL) ORM : GORM v1 (mapping uniquement, migrations 100% SQL)

Stratégie de migration

• Migrations SQL pures dans veza-backend-api/migrations/ (001 à 115+)
• GORM utilisé uniquement pour le mapping Go ↔ PostgreSQL, pas pour la création de schéma
• AutoMigrate() est vide — tout est géré par SQL
• Outil : go run ./cmd/migrate_tool/main.go up (ou down pour rollback)
• Table schema_migrations pour le suivi des migrations appliquées

Conventions

• Clés primaires : UUID v4 (uuid.UUID avec google/uuid)
• Soft delete : Colonne deleted_at indexée sur 20+ tables
• Timestamps : created_at, updated_at sur toutes les tables
• JSONB : Utilisé pour les données flexibles (social_links, specs, metadata)
• Enums : Types PostgreSQL custom (user_role, track_status, etc.)
• Foreign keys : Contraintes PostgreSQL natives, toujours actives

A. Utilisateurs & Authentification

users

Table centrale — profil utilisateur.

Relations : roles (M2M via user_roles), track_likes (has many, CASCADE)

sessions

refresh_tokens

roles

Relations : users (M2M), permissions (M2M)

permissions

user_roles (table pivot)

role_permissions (table pivot)

mfa_configs

recovery_codes

webauthn_credentials

federated_identities

api_keys

user_settings

user_profiles

user_presence

B. Pistes audio

tracks

Table principale des pistes audio.

Relations : user (belongs to), playlists (M2M), likes (has many), shares (has many), versions (has many), hls_streams (has many)

track_versions

track_likes

track_plays

track_shares

track_comments

Relations : parent (self-ref), replies (has many self-ref)

track_reposts

track_stems

track_lyrics

track_history

tags

track_tags (pivot)

genres

track_genres (pivot)

playback_analytics

C. Playlists

playlists

Relations : user (belongs to), tracks (has many PlaylistTrack), collaborators (has many, CASCADE)

playlist_tracks (pivot ordonné)

playlist_collaborators

playlist_follows

playlist_share_links

playlist_versions

user_genre_follows (pivot)

user_tag_follows (pivot)

D. Chat & Messagerie

rooms

Relations : members (has many, CASCADE), messages (has many, CASCADE)

room_members

room_invitations

messages

message_reactions

read_receipts

delivered_status

E. Streaming & Collaboration

hls_streams

hls_transcode_queue

live_streams

co_listening_sessions

queues

queue_items

queue_sessions (sessions collaboratives)

shared_queue_items

F. Fichiers & Stockage

user_files

user_folders

Relations : parent (self-ref), children (has many), files (has many)

cloud_file_versions

cloud_file_shares

user_storage_quotas

G. Équipement (Gear)

gear_items

gear_images

gear_repairs

gear_documents

H. Paiements & Royalties

seller_stripe_accounts