# Options non implémentées - Analyse d'intérêt **Author:** Équipe 4NK **Date:** 2026-01-28 ## 1. Merkle trees (optionnel) ### Description Checkpointing / accélération de scan pour optimiser la synchronisation à grande échelle. ### Intérêt **Avantages potentiels :** - **Performance** : Réduction significative du nombre de requêtes nécessaires pour synchroniser de grandes quantités de données - **Scalabilité** : Permet de gérer des volumes importants (millions de messages) sans dégradation de performance - **Efficacité réseau** : Réduction de la bande passante utilisée lors des synchronisations - **Checkpointing** : Possibilité de reprendre une synchronisation depuis un point précis sans tout re-scanner **Cas d'usage :** - Services avec un très grand nombre de messages (millions) - Synchronisations fréquentes sur de grandes fenêtres temporelles - Réseaux avec bande passante limitée - Besoin de synchronisation incrémentale efficace ### Inconvénients / Complexité **Complexité technique :** - Implémentation complexe (construction d'arbres de Merkle, gestion des segments) - Nécessite une coordination entre client et serveur (relais doit supporter Merkle) - Gestion des conflits et des branches d'arbres - Maintenance et debugging plus difficiles **Coût de développement :** - Temps de développement important - Tests complexes (volumes importants, cas limites) - Documentation et formation nécessaires **Alternatives existantes :** - **Bloom filter** : Déjà implémenté, réduit efficacement les requêtes inutiles - **Hash cache** : Déjà implémenté, évite de traiter les messages déjà vus - **Fenêtre de scan configurable** : Permet de limiter la portée des synchronisations ### Recommandation **Intérêt : MOYEN à FAIBLE** **Raisons :** 1. **Bloom filter suffisant** : Le Bloom filter déjà implémenté couvre la majorité des cas d'usage d'optimisation 2. **Complexité vs bénéfice** : La complexité d'implémentation est élevée pour un gain marginal dans la plupart des cas 3. **Volumes actuels** : Les volumes de données actuels ne justifient pas nécessairement cette optimisation 4. **Dépendance serveur** : Nécessite une modification des relais pour supporter Merkle, ce qui limite l'adoption **Quand l'implémenter :** - Si les volumes de messages deviennent très importants (millions+) - Si les synchronisations deviennent un goulot d'étranglement mesurable - Si le Bloom filter ne suffit plus pour optimiser les requêtes - Si les relais sont prêts à supporter Merkle **Conclusion :** Optionnel, à considérer uniquement si un besoin réel de performance à grande échelle est identifié et mesuré. --- ## 2. Évolutions futures api-relay (optionnel) ### Description Plusieurs évolutions possibles pour api-relay : base de données, authentification, WebSocket, compression, etc. ### Analyse par évolution #### 2.1 Base de données (SQLite, PostgreSQL) **Intérêt : ÉLEVÉ** **Avantages :** - **Persistance fiable** : Données persistées de manière fiable, pas de perte en cas de redémarrage - **Performance** : Requêtes optimisées, indexation efficace - **Scalabilité** : Gestion de volumes importants - **Transactions** : Garanties ACID pour la cohérence des données - **Maintenance** : Outils de backup, monitoring, maintenance standardisés **Inconvénients :** - Configuration et déploiement plus complexes - Nécessite une migration depuis le stockage en mémoire actuel **Recommandation :** **À implémenter en production**. Le stockage en mémoire actuel est suffisant pour le développement mais pas pour la production. --- #### 2.2 Authentification pour endpoints POST **Intérêt : MOYEN** **Avantages :** - **Sécurité** : Protection contre les abus (spam, DoS) - **Traçabilité** : Identification des sources de messages - **Contrôle d'accès** : Limitation à des clients autorisés **Inconvénients :** - Complexité de gestion des clés/tokens - Nécessite une infrastructure d'authentification - Peut limiter la décentralisation (nécessite une autorité pour émettre les tokens) **Recommandation :** **Optionnel**. Utile si des problèmes d'abus sont identifiés. Le modèle actuel (pull-only, déduplication par hash) offre déjà une certaine protection. --- #### 2.3 Compression des messages stockés **Intérêt : FAIBLE** **Avantages :** - Réduction de l'espace disque - Réduction de la bande passante réseau **Inconvénients :** - CPU supplémentaire pour compression/décompression - Complexité de gestion (format, version) - Les messages sont déjà relativement petits (JSON) **Recommendation :** **Non prioritaire**. Les messages sont déjà compacts (JSON). La compression n'apporterait qu'un gain marginal. --- #### 2.4 Indexation avancée (service UUID, type UUID) **Intérêt : MOYEN** **Avantages :** - Requêtes plus rapides pour des filtres spécifiques - Meilleure performance sur de gros volumes **Inconvénients :** - Complexité de gestion des index - Maintenance supplémentaire **Recommandation :** **Optionnel**. L'indexation par `service_uuid` est déjà partiellement implémentée. À améliorer si les volumes augmentent. --- #### 2.5 WebSocket pour notifications en temps réel **Intérêt : FAIBLE à MOYEN** **Avantages :** - Notifications en temps réel (push) - Réduction de la latence - Meilleure expérience utilisateur **Inconvénients :** - **Contradiction avec le modèle pull-only** : Le modèle actuel est volontairement pull-only pour la décentralisation - Complexité de gestion des connexions WebSocket - Nécessite une infrastructure serveur plus complexe - Peut compromettre la décentralisation (dépendance au serveur) **Recommandation :** **Non recommandé**. Contredit le principe de décentralisation et le modèle pull-only. Le polling actuel est suffisant et plus robuste. --- #### 2.6 Métriques Prometheus **Intérêt : ÉLEVÉ** **Avantages :** - Monitoring et observabilité - Détection proactive des problèmes - Métriques de performance **Inconvénients :** - Configuration supplémentaire - Infrastructure de monitoring nécessaire **Recommandation :** **À implémenter en production**. Déjà partiellement implémenté (`GET /metrics`). À compléter selon les besoins de monitoring. --- #### 2.7 Logging structuré (Winston, Pino) **Intérêt : ÉLEVÉ** **Avantages :** - Meilleure traçabilité - Analyse des logs facilitée - Debugging plus efficace **Inconvénients :** - Configuration supplémentaire - Gestion des logs (rotation, stockage) **Recommandation :** **Déjà implémenté**. Pino est déjà utilisé dans api-relay. À maintenir et améliorer si nécessaire. --- ## Synthèse ### À implémenter en priorité 1. **Base de données** (SQLite/PostgreSQL) - Production 2. **Métriques Prometheus** - Compléter l'implémentation existante ### Optionnel selon besoins 3. **Authentification POST** - Si problèmes d'abus 4. **Indexation avancée** - Si volumes importants ### Non recommandé 5. **Compression** - Gain marginal 6. **WebSocket** - Contredit le modèle pull-only décentralisé ### Déjà en place 7. **Logging structuré** - Pino déjà implémenté 8. **Rate limiting** - Déjà implémenté 9. **CORS** - Déjà implémenté 10. **Bloom filter** - Déjà implémenté --- ## Conclusion Les évolutions les plus pertinentes pour api-relay sont : - **Base de données** : Nécessaire pour la production - **Métriques** : Utile pour le monitoring Les autres évolutions sont optionnelles et dépendent des besoins spécifiques identifiés en production.