4nk/story-research-zapwall
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
story-research-zapwall/docs/architecture-implementation-status.md
Nicolas Cantu b2e6250ff5 lint fix wip
2026-01-07 01:51:26 +01:00

4.4 KiB
Raw Blame History

État d'implémentation de l'architecture

Auteur : Équipe 4NK Date : 2025-01-27

Vue d'ensemble

Ce document décrit l'état actuel de l'implémentation des principes d'architecture et les migrations nécessaires.

Services créés

✅ Services conformes aux principes

  1. lib/websocketService.ts - Service de gestion des WebSockets

    • Gère les connexions WebSocket
    • Communique avec les Service Workers via swClient
    • ✅ Conforme aux principes

  2. lib/writeOrchestrator.ts - Service de gestion des écritures

    • Orchestre les écritures vers WebSockets/API et Web Worker d'écriture
    • ✅ Conforme aux principes

  3. lib/writeService.ts - Service de gestion du Web Worker d'écriture

    • Existe déjà et route les écritures vers le Web Worker
    • ⚠️ Le fichier writeWorker.js doit être créé et adapté pour Next.js

  4. lib/notificationReader.ts - Service de lecture des notifications

    • Détecte les nouvelles notifications dans IndexedDB
    • Séparé du Service Worker qui alimente les notifications
    • ✅ Conforme aux principes

  5. lib/notificationService.ts - Service de gestion des notifications

    • Stocke les notifications dans IndexedDB
    • ✅ Conforme aux principes

  6. lib/notificationDetector.ts - Détecteur de notifications

    • Scanne IndexedDB pour détecter les nouveaux événements
    • ⚠️ Doit être intégré dans le Service Worker pour alimenter les notifications

Migrations nécessaires

🔄 Migrations prioritaires

  1. Créer et adapter writeWorker.js

    • Le fichier public/writeWorker.js existe mais doit être adapté pour Next.js
    • Les Web Workers dans Next.js nécessitent une configuration spéciale
    • Action : Adapter le worker pour fonctionner avec Next.js ou utiliser une approche alternative

  2. Migrer les écritures directes vers writeService

    • Plusieurs services appellent directement objectCache.set et objectCache.updatePublished
    • Fichiers concernés :
      • lib/platformSync.ts - Synchronisation plateforme
      • lib/userContentSync.ts - Synchronisation contenu utilisateur
      • lib/articlePublisher.ts - Publication d'articles
      • lib/purchaseQueries.ts - Requêtes d'achats
      • lib/reviewTipQueries.ts - Requêtes de tips
      • lib/sponsoringQueries.ts - Requêtes de sponsoring
    • Action : Remplacer tous les appels directs par writeService.writeObject() et writeService.updatePublished()

  3. Intégrer le Service Worker pour les notifications

    • Le Service Worker doit alimenter directement la table des notifications via le Web Worker d'écriture
    • Actuellement, le détecteur s'exécute dans le thread principal
    • Action : Modifier public/sw.js pour que le Service Worker alimente les notifications via writeService.createNotification()

  4. Utiliser websocketService au lieu de nostrService.pool

    • nostrService utilise directement SimplePool pour les WebSockets
    • Action : Migrer vers websocketService qui communique avec les Service Workers

  5. Utiliser writeOrchestrator pour les publications

    • Les publications doivent passer par writeOrchestrator qui orchestre WebSocket + Web Worker
    • Action : Modifier nostrService.publishEvent() pour utiliser writeOrchestrator

Architecture cible

Interface Utilisateur (React)
    ↓ (lecture uniquement)
IndexedDB
    ↑ (écriture via Web Worker)
Web Worker d'écriture (writeWorker.js)
    ↑ (orchestration)
Service de gestion des écritures (writeOrchestrator)
    ↓ (réseau)
Service WebSocket (websocketService)
    ↓ (communication)
Service Workers (sw.js)
    ↓ (persistance via Web Worker)
Web Worker d'écriture
    ↓
IndexedDB

Priorités

  1. Haute priorité : Créer et adapter writeWorker.js pour Next.js
  2. Haute priorité : Migrer les écritures de synchronisation vers writeService
  3. Moyenne priorité : Intégrer le Service Worker pour alimenter les notifications
  4. Moyenne priorité : Migrer vers websocketService
  5. Basse priorité : Utiliser writeOrchestrator pour les publications

Notes

  • Les services de configuration (configStorage, settingsCache) peuvent continuer à écrire directement dans IndexedDB car ils ne sont pas des données métier
  • Les services de log (publishLog) peuvent continuer à écrire directement car ce sont des logs
  • La migration doit être progressive pour éviter de casser l'application