# É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