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

Documentation technique

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

1. Contexte et Problématique1/2

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.

1. Contexte et Problématique2/2

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 :

En développement local : Utilisation de HTTP classique (fetch('http://localhost:8789/test-direct')) pour tester sans infrastructure Cloudflare.
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.