# Service Worker pour la synchronisation

**Auteur** : Équipe 4NK

## Vue d'ensemble

La synchronisation utilise maintenant un Service Worker pour fonctionner en arrière-plan, même lorsque l'onglet est fermé. Le système fonctionne en mode hybride : il utilise le Service Worker si disponible, sinon il revient à l'implémentation classique avec `setInterval`.

## Architecture

### Composants

1. **Service Worker** (`public/sw.js`)
   - Gère les événements de synchronisation périodique
   - Communique avec le thread principal via `postMessage`
   - Utilise l'API Periodic Background Sync si disponible

2. **Service Worker Client** (`lib/swClient.ts`)
   - Interface de communication avec le Service Worker
   - Enregistre et gère le Service Worker
   - Envoie des messages au Service Worker

3. **Service Worker Sync Handler** (`lib/swSyncHandler.ts`)
   - Écoute les requêtes du Service Worker
   - Exécute les opérations de synchronisation dans le thread principal
   - Accède à `nostrService`, `IndexedDB`, etc.

### Flux de synchronisation

```
Service Worker (sw.js)
    ↓ (postMessage)
Thread Principal (swSyncHandler)
    ↓ (exécution)
Services (platformSync, userContentSync, publishWorker)
    ↓ (mise à jour)
IndexedDB
```

## Fonctionnalités

### Synchronisation de la plateforme

- **Déclenchement** : Toutes les 60 secondes
- **Service Worker** : Utilise `periodicSync` si disponible
- **Fallback** : `setInterval` dans le thread principal

### Synchronisation du contenu utilisateur

- **Déclenchement** : Lors de la connexion ou navigation
- **Service Worker** : Peut fonctionner en arrière-plan
- **Fallback** : Exécution directe dans le thread principal

### Worker de republication

- **Déclenchement** : Toutes les 30 secondes
- **Service Worker** : Utilise `periodicSync` si disponible
- **Fallback** : `setInterval` dans le thread principal

## Avantages

1. **Fonctionne en arrière-plan** : La synchronisation continue même si l'onglet est fermé
2. **Réduction de l'impact** : Les opérations lourdes sont déplacées du thread principal
3. **Meilleure expérience utilisateur** : Synchronisation transparente sans bloquer l'interface

## Limitations

1. **WebSockets** : Les connexions WebSocket doivent être gérées dans le thread principal
2. **IndexedDB** : Accès direct depuis le Service Worker, mais les opérations complexes sont exécutées dans le thread principal
3. **Compatibilité** : Nécessite un navigateur supportant les Service Workers et l'API Periodic Background Sync (optionnel)

## Configuration

Le Service Worker est automatiquement enregistré au démarrage de l'application dans `pages/_app.tsx`.

### Désactiver le Service Worker

Pour désactiver le Service Worker et revenir à l'implémentation classique :

```typescript
// Dans lib/platformSync.ts, lib/publishWorker.ts, etc.
// Retirer les appels à swClient
```

## Dépannage

### Le Service Worker ne se charge pas

1. Vérifier que le fichier `public/sw.js` existe
2. Vérifier la console du navigateur pour les erreurs
3. Vérifier que HTTPS est utilisé (requis pour les Service Workers en production)

### La synchronisation ne fonctionne pas

1. Vérifier que `swSyncHandler.initialize()` est appelé
2. Vérifier les messages dans la console : `[SW]`, `[SWClient]`, `[SWSyncHandler]`
3. Vérifier que les services de synchronisation sont correctement initialisés

### Mise à jour du Service Worker

Le Service Worker se met à jour automatiquement. Si une nouvelle version est détectée, l'application se recharge automatiquement.

## Modalités de déploiement

1. Le fichier `public/sw.js` est servi automatiquement par Next.js
2. Le Service Worker est enregistré au premier chargement de l'application
3. Les mises à jour sont gérées automatiquement

## Modalités d'analyse

- Console navigateur : Messages `[SW]`, `[SWClient]`, `[SWSyncHandler]`
- DevTools > Application > Service Workers : État du Service Worker
- DevTools > Network : Requêtes de synchronisation