story-research-zapwall/docs/service-worker-sync.md
2026-01-07 01:51:26 +01:00

114 lines
3.9 KiB
Markdown

# 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