Architecture - its-abdou/slack-clone GitHub Wiki

🏗️ Architecture Globale

Architecture Diagram

L'architecture de l'application suit un modèle **client-serveur moderne** avec séparation claire des responsabilités :
  • Frontend (React) : Interface utilisateur réactive avec communication HTTPS REST vers le backend
  • Backend (Express.js) : API REST qui orchestre les services externes et la base de données
  • Services Externes :
    • Clerk pour l'authentification
    • Stream pour le chat et la vidéo en temps réel
    • Inngest pour les tâches asynchrones
    • Sentry pour le monitoring
  • Data Layer (MongoDB) : Stockage persistant des données utilisateurs et configurations
  • Deployment : CI/CD via GitHub Actions, conteneurisation Docker, hébergement sur Google Cloud Run

Structure du Projet

slack-clone/
├── backend/
│   ├── src/
│   │   ├── config/          # Configuration (DB, Stream, Inngest)
│   │   ├── controllers/     # Logique métier
│   │   ├── middleware/      # Auth middleware
│   │   ├── models/          # Schémas MongoDB
│   │   ├── routes/          # Routes API
│   │   └── server.js        # Point d'entrée
│   ├── tests/               # Tests Jest
│   └── Dockerfile
│
├── frontend/
│   ├── src/
│   │   ├── components/      # Composants React
│   │   ├── pages/           # Pages (Auth, Home, Call)
│   │   ├── providers/       # Context providers
│   │   ├── hooks/           # Custom hooks
│   │   └── lib/             # Utilitaires
│   └── Dockerfile
│
├── .github/workflows/       # CI/CD
└── docker-compose.yml

🔄 Flux de Données Temps Réel

1. Authentification Flow

sequenceDiagram
    actor User
    participant Browser
    participant Clerk
    participant Backend
    participant Stream

    User->>Browser: Access Application
    Browser->>Clerk: Display Sign-In Widget
    User->>Clerk: Enter Credentials
    Clerk->>Clerk: POST /api/auth/sign-in
    Clerk->>Browser: JWT Token Generated
    Browser->>Browser: Store Token (Cookies/LocalStorage)
    
    Browser->>Backend: Request with userId & session
    Backend->>Backend: GET /api/chat/token
    Backend->>Stream: Request Stream Token
    Stream->>Backend: Stream Token (JWT)
    Backend->>Browser: Return Stream Token
    Browser->>Browser: Initialize Stream Chat Client
Loading

Points clés :

  • Clerk gère toute la logique d'authentification (OAuth, MFA, etc.)
  • Le backend génère des tokens Stream spécifiques pour chaque utilisateur
  • Les tokens sont stockés de manière sécurisée côté client

2. Messagerie Temps Réel

sequenceDiagram
    participant UserA as User A
    participant SDK as Stream SDK
    participant Backend
    participant StreamAPI as Stream API
    participant UserB as User B

    UserA->>SDK: Send Message
    SDK->>StreamAPI: Publish Message
    StreamAPI->>StreamAPI: Store in Stream DB
    StreamAPI->>Backend: Webhook Event (message.new)
    Backend->>Backend: Process Event
    
    StreamAPI-->>UserA: WebSocket Broadcast
    StreamAPI-->>UserB: WebSocket Broadcast
    
    UserB->>UserB: UI Updates (React State)
    UserB->>UserB: Display Notification
Loading

Caractéristiques :

  • Communication bidirectionnelle via WebSocket
  • Persistence automatique dans Stream Cloud
  • Webhooks pour intégrations backend (analytics, modération, etc.)
  • Synchronisation temps réel entre tous les clients connectés

3. Appels Vidéo

sequenceDiagram
    participant UserA as User A (Initiator)
    participant FrontendA as Frontend A
    participant Backend
    participant StreamVideo as Stream Video API
    participant FrontendB as Frontend B
    participant UserB as User B (Receiver)

    UserA->>FrontendA: Click "Start Call"
    FrontendA->>FrontendA: Navigate to /call/:callId
    FrontendA->>Backend: GET /api/chat/token
    Backend->>StreamVideo: Request Video Token
    StreamVideo->>Backend: Video Token
    Backend->>FrontendA: Return Token
    
    FrontendA->>StreamVideo: Initialize StreamVideoClient
    FrontendA->>StreamVideo: Create/Join Call
    StreamVideo->>StreamVideo: Allocate SFU Resources
    
    StreamVideo->>FrontendB: Send Call Notification
    UserB->>FrontendB: Accept Call
    FrontendB->>FrontendB: Navigate to /call/:callId
    FrontendB->>StreamVideo: Join Call
    
    StreamVideo->>FrontendA: WebRTC Connection
    StreamVideo->>FrontendB: WebRTC Connection
    
    Note over FrontendA,FrontendB: P2P Audio/Video Streams<br/>Screen Sharing<br/>Real-time Reactions<br/>Call Recording
Loading

Technologies utilisées :

  • WebRTC pour les flux média peer-to-peer
  • SFU (Selective Forwarding Unit) géré par Stream pour optimiser la bande passante
  • Support de multiples participants avec scalabilité automatique

4. Background Jobs (Inngest)

sequenceDiagram
    participant Clerk
    participant Backend
    participant Inngest as Inngest Server
    participant Handler as Function Handler
    participant Stream

    Clerk->>Backend: Webhook: User Created
    Backend->>Inngest: Trigger Event (user.created)
    Inngest->>Inngest: Queue Job
    Inngest->>Handler: Execute Function
    
    Handler->>Stream: Upsert User in Stream
    Stream->>Handler: User Created
    Handler->>Stream: Add User to Public Channels
    Stream->>Handler: Success
    
    Handler->>Inngest: Job Complete
    Inngest->>Backend: Event Processed
    Backend->>Backend: User Ready
Loading

Cas d'usage des jobs :

  • Onboarding utilisateur : Création dans Stream, ajout aux canaux par défaut
  • Notifications asynchrones : Envoi d'emails, push notifications
  • Nettoyage : Suppression de messages anciens, archivage
  • Analytics : Agrégation de métriques, rapports quotidiens

Avantages d'Inngest :

  • Retry automatique en cas d'échec
  • Scheduling (jobs planifiés)
  • Monitoring et debugging intégré
  • Pas besoin de gérer une queue Redis/RabbitMQ

🔐 Sécurité

Mesures Implémentées

  1. Authentification

    • Clerk JWT tokens avec rotation automatique
    • Middleware protectRoute sur toutes les routes sensibles
    • Validation côté serveur avec vérification des claims

  2. CORS

    • Whitelist des origines autorisées (production uniquement)
    • credentials: true pour cookies sécurisés
    • Headers strictement contrôlés

  3. Variables d'environnement

    • Secrets stockés dans GitHub Secrets et Google Secret Manager
    • Pas de hardcoding de credentials
    • Validation via env.js au démarrage

  4. Error Monitoring

    • Sentry pour tracking d'erreurs production
    • PII (Personally Identifiable Information) excluded des logs
    • Alertes temps réel pour erreurs critiques

  5. Rate Limiting

    • Stream API rate limits configurés
    • Cloud Run auto-scaling avec limites de concurrence
    • Protection DDoS via Cloud Armor (optionnel)

📊 Performance & Scalabilité

Aspect Solution Bénéfice
Horizontal Scaling Cloud Run auto-scale Adaptation automatique au trafic
CDN Assets statiques via Nginx Latence réduite pour utilisateurs globaux
Lazy Loading Code splitting avec Vite Temps de chargement initial optimisé
WebSocket Connexions persistantes Temps réel sans polling
Database Indexing MongoDB indexes sur userId, channelId Requêtes 10x plus rapides
Caching React Query cache côté client Réduction de 80% des appels API

📈 Monitoring & Observabilité

Métriques Clés Surveillées

  • Frontend : Core Web Vitals (LCP, FID, CLS) via Sentry
  • Backend : Temps de réponse API, taux d'erreur, utilisation CPU/RAM
  • Database : Slow queries, taille de collection, index hit ratio
  • Stream : Messages/seconde, durée moyenne des appels, qualité vidéo

Alertes Configurées

  • Taux d'erreur > 5% sur 5 minutes
  • Temps de réponse > 2s sur endpoints critiques
  • CPU > 80% pendant 10 minutes
  • Échec de déploiement CI/CD

Retour à Home | Précédent : Présentation | Suivant : Veille Technologique

⚠️ **GitHub.com Fallback** ⚠️