EmDash et l’ecosysteme Cloudflare : synergie parfaite

EmDash a fait le pari de construire son CMS entierement sur l’ecosysteme Cloudflare. Ce n’est pas un simple choix d’hebergement : chaque brique de l’infrastructure Cloudflare joue un role precis dans l’architecture d’EmDash. Workers pour le compute, D1 pour les donnees, R2 pour les medias, KV pour le cache, Queues pour les taches asynchrones. Ce dossier analyse cette synergie service par service, evalue les couts et explore les perspectives de scalabilite.

La vision : un CMS edge-native

La plupart des CMS sont concus pour fonctionner sur un serveur centralise. Meme les CMS headless modernes deploient generalement leur API sur un serveur unique (ou un cluster) dans une seule region. EmDash prend le contre-pied de cette approche en etant concu des le depart pour fonctionner sur le reseau edge de Cloudflare, present dans plus de 300 villes a travers le monde.

Cela signifie que :

Le code s’execute au plus pres de l’utilisateur
Les donnees sont distribuees globalement
Il n’y a pas de serveur a gerer, pas d’OS a mettre a jour, pas de scaling a configurer
Le temps de reponse est quasi identique que votre visiteur soit a Paris, Tokyo ou Sao Paulo

Workers : le moteur de compute

Role dans EmDash

Cloudflare Workers est le runtime d’execution d’EmDash en production. Il remplace le serveur Node.js traditionnel. Le code Astro compile est deploye comme un Worker qui gere :

Le rendu SSR (Server-Side Rendering) des pages dynamiques
L’API d’administration du CMS
Le traitement des soumissions de formulaires
L’execution des hooks de plugins
L’authentification et les sessions

Avantages pour EmDash

Demarrage instantane : un Worker demarre en moins de 5 ms, contre plusieurs centaines de millisecondes pour un conteneur Docker ou un processus Node.js. Il n’y a pas de “cold start” perceptible.

Execution distribuee : chaque requete est traitee par le datacenter Cloudflare le plus proche du visiteur. Pour un site avec une audience internationale, c’est un avantage considerable.

Isolation : chaque requete s’execute dans un environnement isole (V8 isolate), offrant une securite renforcee sans la lourdeur des conteneurs.

Limites

Temps d’execution : un Worker est limite a 30 secondes (plan Paid) par requete. C’est largement suffisant pour EmDash, mais impose de deleguer les taches longues aux Queues.
Memoire : 128 Mo par Worker. Aucune page EmDash ne s’approche de cette limite en pratique.
Compatibilite Node.js : Workers utilise le runtime V8, pas Node.js. La plupart des API Node.js sont supportees via des polyfills, mais certaines bibliotheques peuvent ne pas fonctionner.

D1 : la base de donnees

Role dans EmDash

D1 est la base de donnees principale d’EmDash en production. Elle stocke :

Les articles, pages et contenus de toutes les collections
Les utilisateurs et leurs permissions
Les commentaires
Les soumissions de formulaires
Les metadonnees des medias
Les configurations de plugins

D1 est une base SQLite distribuee, ce qui offre la simplicite de SQLite avec la scalabilite du reseau Cloudflare.

Avantages pour EmDash

Compatibilite SQLite : EmDash utilise la meme syntaxe SQL en developpement local (SQLite natif) et en production (D1). Pas de divergence entre les environnements.

Performances de lecture : D1 replique les donnees en lecture dans les datacenters proches des visiteurs. Les requetes de lecture (qui representent la majorite du trafic d’un CMS) sont donc extremement rapides.

Cout : D1 est genereux dans son free tier (5 millions de lectures/jour, 100 000 ecritures/jour). Pour un blog ou un site vitrine, le cout est souvent nul.

Sauvegardes automatiques : D1 effectue des sauvegardes automatiques avec point-in-time recovery sur 30 jours.

Limites

Latence d’ecriture : les ecritures sont centralisees dans une seule region (celle du “primary” D1). La latence d’ecriture peut etre plus elevee pour les administrateurs eloignes de cette region. En pratique, cela se traduit par quelques dizaines de millisecondes supplementaires lors de la publication d’un article, ce qui est imperceptible.
Taille maximale : 10 Go par base de donnees. Largement suffisant pour un CMS, mais a surveiller pour les sites avec des millions d’entrees.
Transactions : D1 supporte les transactions, mais avec certaines restrictions par rapport a un PostgreSQL complet.

R2 : le stockage objets

Role dans EmDash

R2 stocke tous les fichiers medias d’EmDash : images, documents PDF, videos, fichiers uploades via les formulaires. R2 est compatible S3, ce qui facilite les integrations et les migrations.

Avantages pour EmDash

Pas de frais de sortie : contrairement a S3, R2 ne facture pas le trafic sortant. Pour un site avec beaucoup d’images, c’est une economie significative.

Performance : les fichiers sont servis depuis le reseau edge de Cloudflare, avec mise en cache automatique.

Compatibilite S3 : les outils qui fonctionnent avec S3 fonctionnent avec R2. Vous pouvez utiliser le CLI AWS, rclone ou tout autre outil compatible.

Integration avec le pipeline d’images

EmDash utilise R2 en combinaison avec Cloudflare Images (ou le transformateur d’images Worker) pour :

Stocker les images originales dans R2
Generer des variantes optimisees a la volee (redimensionnement, format WebP/AVIF)
Cacher les variantes dans le CDN Cloudflare
Servir la variante optimale selon le navigateur et la taille d’ecran

Upload → R2 (original) → Image Transform → CDN Cache → Visiteur
                              ↑
                    Parametres URL (?w=800&f=webp)

Limites

Pas de CDN natif : R2 n’expose pas les fichiers directement via un CDN. Il faut utiliser un Worker ou un Custom Domain pour servir les fichiers. EmDash gere cela automatiquement.
Pas de traitement d’image integre : le redimensionnement et la conversion de format necessitent Cloudflare Images ou un Worker dedie.

KV : le cache distribue

Role dans EmDash

Cloudflare KV (Key-Value) est utilise par EmDash comme couche de cache distribuee :

Cache des pages renderees pour eviter le re-rendu SSR
Cache des requetes D1 frequentes
Stockage des sessions utilisateur
Stockage des configurations de plugins
Cache des metadonnees de medias

Avantages pour EmDash

Latence de lecture ultra-faible : KV est replique dans tous les datacenters Cloudflare. Les lectures sont quasi instantanees (< 10 ms).

Simplicite : pas de Redis a configurer, pas de Memcached a gerer. KV est un service manage avec une API simple.

Strategie de cache EmDash

EmDash utilise une strategie de cache a plusieurs niveaux :

Requete visiteur
    │
    ▼
[1] Cache CDN Cloudflare (pages statiques)
    │ MISS
    ▼
[2] Cache KV (pages dynamiques renderees)
    │ MISS
    ▼
[3] Worker SSR (rendu + requete D1)
    │
    ▼
[4] Stockage dans KV + reponse

L’invalidation du cache est geree automatiquement par EmDash : lorsqu’un contenu est modifie, les cles KV correspondantes sont purgees.

Limites

Coherence eventuelle : KV est “eventually consistent”. Apres une ecriture, la nouvelle valeur peut mettre jusqu’a 60 secondes a se propager dans tous les datacenters. EmDash gere cela en invalidant le cache de maniere proactive.
Taille des valeurs : 25 Mo maximum par valeur. Suffisant pour une page HTML, mais pas pour des fichiers volumineux (utiliser R2 pour cela).

Queues : les taches asynchrones

Role dans EmDash

Cloudflare Queues gere les taches qui ne doivent pas bloquer la requete HTTP :

Envoi des webhooks (plugin Webhook Notifier)
Envoi des emails de notification
Classification AI des commentaires (plugin AI Moderation)
Generation des sitemaps et flux RSS
Cross-posting vers Bluesky (plugin AT Protocol)
Taches cron des plugins

Avantages pour EmDash

Decouplage : les taches longues ou sujettes a erreur sont executees de maniere asynchrone. La publication d’un article est instantanee ; les notifications sont envoyees en arriere-plan.

Fiabilite : Queues garantit la livraison des messages avec retry automatique. Si un webhook echoue, il sera retente selon une strategie de backoff exponentiel.

Batching : Queues peut regrouper les messages pour un traitement efficace. Par exemple, les metriques analytics sont regroupees avant d’etre ecrites dans D1.

Limites

Latence : les messages sont traites en quelques secondes, pas en millisecondes. Ce n’est pas adapte pour les operations qui necessitent un retour immediat.
Taille des messages : 128 Ko par message. Suffisant pour les metadonnees, mais pas pour les fichiers (utiliser R2 comme stockage intermediaire).

Analyse des couts

Free tier Cloudflare

Le free tier de Cloudflare est remarquablement genereux pour un CMS :

Service	Free tier
Workers	100 000 requetes/jour
D1	5M lectures/jour, 100K ecritures/jour
R2	10 Go stockage, 10M lectures/mois
KV	100 000 lectures/jour, 1 000 ecritures/jour
Queues	1 million messages/mois

Pour un blog ou un site vitrine avec quelques milliers de visiteurs par jour, le free tier suffit.

Plan Workers Paid (5 $/mois)

Le plan Paid debloque des limites bien plus elevees :

Service	Inclus	Au-dela
Workers	10M requetes/mois	0.30 $/million
D1	25 milliards lectures/mois	0.001 $/million
R2	10 Go stockage	0.015 $/Go/mois
KV	10M lectures/mois	0.50 $/million
Queues	1M messages/mois	0.40 $/million

Estimation pour differents profils

Blog personnel (1 000 visiteurs/jour) : gratuit ou 5 $/mois Site d’entreprise (10 000 visiteurs/jour) : 5 a 15 $/mois Media en ligne (100 000 visiteurs/jour) : 15 a 50 $/mois Site a fort trafic (1 million de visiteurs/jour) : 50 a 200 $/mois

A titre de comparaison, un hebergement WordPress manage comparable coute 50 a 500 $/mois pour des performances souvent inferieures. Notre article 5 raisons d’essayer EmDash detaille ces avantages economiques.

Scalabilite

Scaling automatique

L’un des plus grands avantages de l’ecosysteme Cloudflare est le scaling automatique. Il n’y a aucune configuration a faire :

Workers : scalent automatiquement de 0 a des millions de requetes par seconde
D1 : les replicas de lecture scalent automatiquement
R2 : pas de limite de stockage pratique
KV : distribue dans 300+ datacenters

Gestion des pics de trafic

Un article devient viral sur Hacker News ou Reddit ? EmDash sur Cloudflare encaisse le pic sans broncher. Les pages cachees dans le CDN sont servies sans meme toucher le Worker. Les pages dynamiques sont cachees dans KV apres le premier rendu. Le “hug of death” n’est tout simplement pas un probleme.

Perspectives d’integration futures

L’ecosysteme Cloudflare continue d’evoluer et EmDash pourra tirer parti de nouveaux services :

Cloudflare AI Gateway : proxy intelligent pour les appels aux LLMs, avec cache et rate limiting
Hyperdrive : connexion rapide aux bases de donnees PostgreSQL externes pour les sites qui ont besoin de SQL avance
Vectorize : base de donnees vectorielle pour la recherche semantique dans le contenu
Browser Rendering : generation de screenshots et de PDFs cote serveur
Workflows : orchestration de taches longues avec etat persistant

Notre conclusion

La synergie entre EmDash et Cloudflare n’est pas un argument marketing : c’est une realite technique mesurable. Chaque service Cloudflare remplit un role precis dans l’architecture du CMS, et l’ensemble offre des performances, une fiabilite et un rapport cout/efficacite difficiles a egaliser avec une infrastructure traditionnelle. Le principal risque est le vendor lock-in : EmDash est profondement integre a Cloudflare, et une migration vers un autre fournisseur de cloud serait un chantier consequent. C’est le compromis a accepter pour beneficier de cette synergie. Pour la grande majorite des projets, c’est un compromis largement favorable.

Pour aller plus loin

Deployer EmDash sur Cloudflare — le guide de deploiement pas a pas
L’architecture technique d’EmDash — comprendre les choix architecturaux du CMS
Mettre EmDash en production — checklist et guide complet de mise en production
Decouvrir EmDash — presentation generale du projet
5 raisons d’essayer EmDash — les arguments cles pour adopter EmDash