Cette analyse technique sur la gestion du cache CDN complète parfaitement la stratégie de performance de Circuy . L'utilisation judicieuse des méthodes HTTP et la gestion des en-têtes d'authentification sont essentielles pour garantir que le SDK reste ultra-léger et réactif. [1, 2] Voici une synthèse de ces recommandations intégrée à l'architecture technique du projet :

Optimisation du Cache CDN et Stratégie de Requêtes

Pour concilier sécurité et performance, l'architecture de communication entre le SDK, l'Extension et le Backend doit suivre des protocoles distincts.

1. Lecture des Parcours (SDK → API)

Pour que le SDK puisse charger les scénarios en moins de 20ms, il est impératif d'utiliser des requêtes GET , les seules aptes à être mises en cache par les serveurs Edge (Cloudflare, CloudFront, Scaleway CDN). [2, 3]

• Problématique de l'en-tête Authorization : Les CDN bypassent souvent le cache lorsqu'ils détectent un en-tête Authorization: Bearer.
• Solution préconisée (Option A) : Passer la clé publique directement dans l'URL (Query String). Cela permet au CDN de générer une Cache Key unique basée sur l'URL complète, incluant l'identifiant client et le chemin de la page. [4]
  • Exemple : GET https://api.circuy.com/v1/tours?api_key=pk_live_123&path=/dashboard
• Alternative (Option B) : Forcer l'en-tête Cache-Control: public, max-age=300 dans la réponse de l'API Hono pour autoriser explicitement le stockage en cache malgré la présence d'identifiants. [3]

2. Sauvegarde des Parcours (Extension → API)

Contrairement au SDK, l'extension utilise des requêtes POST (ou PUT/PATCH) pour publier de nouveaux scénarios. [5]

• Comportement : Ces requêtes ne sont jamais mises en cache . Elles atteignent directement l'API et la base de données PostgreSQL pour garantir une persistance immédiate des données. [3]
• Sécurité : L'utilisation de Authorization: Bearer avec un token de session (JWT) est ici la norme, car la performance du cache n'est pas un facteur pour l'édition. [6, 7]

3. Cycle de Vie du Cache et "Zero Redeploy"

Cette architecture permet une mise à jour instantanée sans redéploiement du code client : [8]

1. Publication : L'utilisateur clique sur "Publier" dans l'extension Chrome. [5]
2. Invalidation : L'API reçoit le POST, met à jour la base de données et déclenche simultanément un appel à la Cache Purge API du CDN.
3. Propagation : Le cache est vidé instantanément sur le réseau Edge.
4. Actualisation : Le prochain visiteur sur le site client récupère la nouvelle version du JSON via une requête GET fraîche, exécutée de manière asynchrone par le SDK. [2]

Bilan de Performance

En déplaçant la logique de filtrage et de stockage vers un CDN configuré de cette manière, vous respectez la contrainte stricte d'un bundle < 15 KB tout en assurant une disponibilité mondiale immédiate de vos parcours d'onboarding. [1, 9] Souhaitez-vous que je génère un rapport technique complet sur l'implémentation de cette stratégie de cache ou un quiz pour valider ces concepts d'architecture réseau ?