ADR: Utilisation de Service Binding Cloudflare pour l'inter-Worker communication

• Statut : Accepté
• Date : 2026-09-16
• Auteur : Devin

---

1. Contexte et Problématique

L’endpoint /api/submit dans Astro doit déléguer la validation et la mise en queue des soumissions de formulaire au Worker form-handler. En production, les deux Workers sont déployés sur Cloudflare, et la communication doit être optimisée pour éviter les appels HTTP externes.

Les besoins sont :

• Communication optimisée entre Workers sur Cloudflare
• Sécurité : éviter l’exposition publique du Worker form-handler
• Performance : minimiser la latence de communication
• Flexibilité : support du développement local (HTTP classique) et de la production (Service Binding)

---

2. Décision Architecturale

Nous décidons d’utiliser Cloudflare Service Binding pour la communication entre l’endpoint /api/submit et le Worker form-handler en production.

L’architecture adoptée est la suivante :

1. En développement local : Utilisation de HTTP classique (fetch('http://localhost:8789/test-direct')) pour tester sans infrastructure Cloudflare.
2. En production : Utilisation du Service Binding FORM_HANDLER fourni par Cloudflare via l’import cloudflare:workers pour une communication interne optimisée.

---

3. Justification du choix

3.1. Pourquoi Cloudflare Service Binding ?

• Performance : Les Service Bindings permettent une communication interne optimisée entre Workers, évitant les appels HTTP externes.
• Sécurité : Le Worker form-handler n’est pas exposé publiquement, uniquement accessible via le Service Binding.
• Latence minimale : La communication interne est plus rapide que les appels HTTP externes.
• Simplicité : L’API Service Binding est native et simplifiée par rapport aux appels HTTP.

3.2. Pourquoi pas d’autres approches ?

• Appels HTTP externes : Exclus car plus lents et nécessitent une exposition publique du Worker form-handler.
• Queue directe depuis Astro : Exclu car Astro ne peut pas produire directement dans une Queue Cloudflare (nécessite un Worker).
• Communication via KV/R2 : Exclu car inadapté au pattern requête/réponse synchrone.

---

4. Conséquences de la décision

Effets Positifs (Avantages)

• Performance optimisée : Communication interne rapide entre Workers.
• Sécurité renforcée : Le Worker form-handler n’est pas exposé publiquement.
• Flexibilité : Support du développement local (HTTP) et de la production (Service Binding).
• Latence minimale : Communication interne optimisée.

Effets Négatifs (Inconvénients & Risques)

• Complexité conditionnelle : Nécessite de gérer deux modes (local vs production) dans le code.
• Dépendance Cloudflare : Utilisation d’une API spécifique Cloudflare (cloudflare:workers).
• Configuration requise : Le Service Binding FORM_HANDLER doit être configuré dans wrangler.toml.

---

5. Alternatives Exclues

• Appels HTTP externes : Exclus car plus lents et nécessitent une exposition publique.
• Queue directe depuis Astro : Exclu car Astro ne peut pas produire directement dans une Queue.
• Communication via KV/R2 : Exclu car inadapté au pattern requête/réponse synchrone.

---

6. Recommandations

• Configuration du Service Binding : Vérifier que le Service Binding FORM_HANDLER est correctement configuré dans apps/web/wrangler.toml.
• Tests locaux : Tester le mode HTTP local avant déploiement.
• Surveillance : Surveiller les logs pour détecter les erreurs de communication entre Workers.
• Documentation : Documenter clairement la dualité des modes (local vs production) dans le guide de développement.