story-research-zapwall/docs/service-worker-sync.md

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 :

// 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