Architecture Proxy + SSR unifiée

Q: Un reverse proxy Nginx ne suffit-il pas ?

**Nginx standard ne peut pas lire un fichier `.env`** et injecter les clés WooCommerce dynamiquement dans une requête proxy **sans module complémentaire** (Lua, auth_request). **Express** le fait naturellement **côté serveur via `process.env`**, sans jamais exposer les clés au navigateur. **Plus simple à maintenir**, plus sûr.

Q: Le mode standalone est-il obligatoire ?

**Oui**. Les modes `server` et `static` d'Astro ne produisent pas le handler SSR réutilisable (`dist/server/entry.mjs`) **nécessaire pour utiliser Astro avec Express**.

Q: Quels sont les risques si on expose les clés WooCommerce ?

**Un attaquant peut consommer votre API WooCommerce** à votre insu, voler des données clients, modifier des produits, ou générer des coûts d'appel API. Ne jamais préfixer les variables de secret par `VITE_`.

Q: Comment tester le proxy en local ?

Lancez Express avec `node server.test.mjs` (pas `astro preview`). En dev local, le proxy pointe vers `http://localhost:3000/api/wp`.

Architecture technique d'un proxy Express intégré à Astro en SSR : schéma de communication entre le navigateur, le serveur Node.js et les API WordPress/WooCommerce

Astro Express Proxy SSR

Comment structurer un site Astro en SSR avec un proxy Express intégré pour dialoguer avec WordPress et WooCommerce sans exposer les clés API.

Roadmap — Développement

Carte interactive

Cette roadmap est conçue pour une navigation sur écran d'ordinateur. Pour une expérience optimale, ouvrez cette page sur un écran plus large.

WordPress d’un côté, Astro de l’autre, et des clés API qui ne doivent jamais toucher le navigateur. Le défi n’est pas de faire fonctionner chaque outil séparément : c’est de les faire dialoguer sans exposer ce qui ne doit pas l’être.

Serveurs à déployer

Astro + Node.js (Express) dans le même processus, même origine

Latence inter-serveur

0ms

Proxy intégré, pas de réseau externe ni CORS à gérer

Petit rappel : Express ≠ truc à part

Express est un framework Node.js qui permet de créer un serveur HTTP. Si vous connaissez Node.js, vous connaissez Express : c’est la brique serveur la plus utilisée dans l’écosystème JavaScript. Quand on dit “serveur Express”, on parle d’un serveur Node.js qui utilise Express.

La Problématique

Le Contexte

Le constat : WordPress et WooCommerce exposent des API REST puissantes, mais les appeler directement depuis le navigateur pose deux problèmes :

CORS : le navigateur bloque les requêtes inter-origines
Sécurité : les clés WooCommerce (consumer_key / consumer_secret) seraient visibles dans le bundle JavaScript.

⚠️

Attention

Les clés WooCommerce (consumer_key / consumer_secret) seraient visibles dans le bundle JavaScript si on ne passe pas par un proxy. Ne jamais préfixer les variables de secret par VITE_.

📖

Quand l'utiliser

Cette architecture est idéale quand vous avez un site en SSR qui doit consommer des API externes sécurisées (WooCommerce, WordPress, Stripe, etc.) sans exposer les clés côté client. Elle remplace un proxy dédié par un serveur unique sur la même origine.

🧠

Analogie

C’est comme un portier d’immeuble : les visiteurs (navigateurs) frappent à la porte du portier (NodeJS), qui vérifie les accès et transmet discrètement aux appartements (WordPress/WooCommerce) sans que les visiteurs connaissent les codes d’entrée. Un seul point d’entrée, sécurisé et centralisé.

La Solution

Adapter Astro en SSR

Le site Astro utilise l’adaptateur @astrojs/node en mode standalone. Cela génère un handler SSR (dist/server/entry.mjs) réutilisable dans n’importe quel serveur Node.js.

Enrober dans Node.Js (Express)

Le handler Astro est importé dans un serveur Express (app.js / server.test.mjs). Express s’occupe de :

Intercepter les routes /api/wp/* pour proxyfier vers WordPress/WooCommerce
Tout le reste (pages Astro, etc.) → délégué au handler Astro SSR

Le proxy intégré

Les routes proxy utilisent les variables d’environnement (côté serveur uniquement) :

plaintext

/api/wp/posts         → WordPress posts API
/api/wp/categories    → WordPress categories API
/api/wp/products      → WooCommerce products API
/api/wp/wc-categories → WooCommerce categories API

Résultats

Fichiers serveur

app.js, server.test.mjs, server.cjs

Routes proxy

Posts, produits, catégories, WC

Défis et enseignements

Erreurs Courantes

Utiliser astro preview avec un proxy

astro preview ne lance pas le proxy Express. Les routes /api/wp/* retournent des 404, ce qui peut faire croire à un problème d’architecture.

Choisir avec Sagesse

Mode standalone + Express = flexibilité maximale

Le mode standalone d’Astro permet d’intégrer le handler SSR dans n’importe quel serveur Express. Une architecture propre et évolutive.

Trois fichiers pour couvrir tous les environnements

app.js (production Passenger), server.test.mjs (preview locale), server.cjs (hébergement legacy) : chaque environnement a son fichier dédié.

Conclusion

Screen proxy mis en place pour un site e-commerce

Une architecture proxy robuste et unifiée

En combinant le mode standalone d’Astro avec un serveur Node.Js personnalisé, nous avons créé une architecture où le rendu SSR et les appels API cohabitent sur la même origin. Fini les problèmes de CORS, fini les clés exposées.

Déploiement o2switch

Comment déployer cette architecture Astro SSR + proxy Express sur un hébergement o2switch avec Passenger ?

Bientôt disponible

En cours de rédaction

Cet article est en cours de rédaction. Inscrivez-vous à la newsletter pour être averti de sa publication.

Newsletter

Un récap par mois de ce qui a vraiment compté. Pas de spam, promis.

Des zones d'ombre ?

Un reverse proxy Nginx ne suffit-il pas ?

Nginx standard ne peut pas lire un fichier .env et injecter les clés WooCommerce dynamiquement dans une requête proxy sans module complémentaire (Lua, auth_request). Express le fait naturellement côté serveur via process.env, sans jamais exposer les clés au navigateur. Plus simple à maintenir, plus sûr.

Le mode standalone est-il obligatoire ?

Oui. Les modes server et static d'Astro ne produisent pas le handler SSR réutilisable (dist/server/entry.mjs) nécessaire pour utiliser Astro avec Express.

Quels sont les risques si on expose les clés WooCommerce ?

Un attaquant peut consommer votre API WooCommerce à votre insu, voler des données clients, modifier des produits, ou générer des coûts d'appel API. Ne jamais préfixer les variables de secret par VITE_.

Comment tester le proxy en local ?

Lancez Express avec node server.test.mjs (pas astro preview). En dev local, le proxy pointe vers http://localhost:3000/api/wp.

Points de vérification

0/5

Le build produit dist/server/entry.mjs (mode standalone)
Le handler SSR Astro est bien importé dans Express
Les routes /api/wp/* sont correctement proxyfiées vers WordPress/WooCommerce
Les variables d'environnement côté serveur (WP_URL, WC clés) sont définies
astro preview n'est pas utilisé pour tester le proxy

Vos progrès sont sauvegardés localement sur votre appareil. Aucune donnée n'est collectée. La durée de conservation dépend de la durée de rétention des données de votre navigateur.

Un serveur unique, zéro CORS, zéro clé exposée : l’architecture Proxy + SSR transforme une contrainte technique en fondation solide pour tout l’écosystème.

Gaëtan Solis

Fondateur, Bao-Link

Orfèvre Digital

Prêt à lancer votre projet ?

Je donne vie à vos idées en créant des sites web et applications intuitifs, esthétiques et fonctionnels.

Disponible

Projets associés

Recommandé

ACM : Refonte E-commerce avec Astro, Express & WordPress

Étude de cas complète : migration d'un site e-commerce WordPress/WooCommerce vers une architecture Astro SSR + proxy Express, avec déploiement et optimisation SEO.

Découvrez d'autres projets

Voir le portfolio

Découvrez le projet

Développement 21 juillet 2026

Bao-Link Documentation : De WordPress à un Écosystème Centré Utilisateur

Le projet Bao-Link raconte l'évolution du site et de ses outils: la création d'un premier site WordPress vitrine, puis le passage à Astro avec un site 100% sur mesure, sans template, centré sur le SEO et l'expérience utilisateur ainsi que les projets liés : diag-application et personas.

Astro WordPress # Migration

Voir le projet

Architecture technique schématique d'un site web moderne

Découvrez le projet

Développement 16 juillet 2026

ACM : Refonte E-commerce avec Astro, Express & WordPress

Étude de cas complète : migration d'un site e-commerce WordPress/WooCommerce vers une architecture Astro SSR + proxy Express, avec déploiement et optimisation SEO.

Astro Express WordPress

Voir le projet

Documentation Soair : création en WordPress puis migration vers Hugo

Découvrez le projet

Développement 16 juillet 2026

Soair : La Transition Numérique Complète

Étude de cas complète : création d'un site WordPress professionnel puis migration vers Hugo pour des performances optimales et un SEO décuplé.

# Soair WordPress Hugo

Voir le projet

Prêt pour l'aventure

Besoin d'un
expert ?

Discutons ensemble de vos objectifs et transformons votre vision en une réalité performante et pérenne.

Lancer la discussion Lire plus d'articles

Architecture Proxy + SSR unifiée

Roadmap — Développement