Aller au contenu principal

Déploiement

:::info État du sujet Le choix d'hébergement n'est pas encore arrêté au moment de la rédaction. Cette page documente ce qui est applicable aujourd'hui (build local, contenu de l'image de prod) et la roadmap envisagée. Elle sera révisée dès qu'un cible est choisi. :::

Vue d'ensemble​

L'application MomBiz Academy se compose des artéfacts déployables suivants :

ArtéfactTypeSourceSortie
APIService Node.jsapps/api/Bundle Nest dans dist/ (node dist/main.js)
Frontend publicSite statiqueapps/frontend-public/dist/ — servi à la racine /
Frontend apprenanteSite statiqueapps/frontend-learner/dist/ — servi sous /learner
Frontend formatriceSite statiqueapps/frontend-teacher/dist/ — servi sous /teacher
Frontend adminSite statiqueapps/frontend-admin/dist/ — servi sous /admin
DocumentationSite statiqueapps/docs/HTML/CSS/JS dans build/ (servi indépendamment)

Les 4 frontends sont servis sous une origine unique derrière un reverse-proxy (cf. ADR 0054). Chaque app est buildée avec un base Vite correspondant à son sous-chemin (/, /learner/, /teacher/, /admin/), donc ses assets ne collisionnent pas avec ceux des autres.

Reverse-proxy origine unique (exemple Caddy)​

exemple.mombiz.app {
  handle_path /admin/*   { root * /srv/frontend-admin/dist   ; try_files {path} /index.html ; file_server }
  handle_path /teacher/* { root * /srv/frontend-teacher/dist ; try_files {path} /index.html ; file_server }
  handle_path /learner/* { root * /srv/frontend-learner/dist ; try_files {path} /index.html ; file_server }
  handle /api/*          { reverse_proxy localhost:3000 }
  handle                 { root * /srv/frontend-public/dist  ; try_files {path} /index.html ; file_server }  # défaut : public
}

Le try_files … /index.html par app assure le fallback SPA (deep-links). L'auth repose sur le localStorage partagé grâce à l'origine unique — pas de cookie cross-domaine.

Builds production​

Lancés depuis la racine du monorepo, dans cet ordre :

npm install --omit=dev=false       # installe les workspaces et leurs deps
npm run build:contracts             # compile les schémas Zod partagés (préalable)
npm run build:api                   # compile le backend NestJS
npm run build:frontend              # build le bundle React
npm --workspace=@app/docs run build # build la documentation Docusaurus

Ou en une commande agrégée :

npm run build                       # exécute build dans tous les workspaces

Vérifier le build​

ls apps/api/dist/main.js                    # → le binaire Node.js
ls apps/frontend-public/dist/index.html     # → entrée de l'app publique
ls apps/frontend-learner/dist/index.html    # → entrée de l'app apprenante
ls apps/frontend-teacher/dist/index.html    # → entrée de l'app formatrice
ls apps/frontend-admin/dist/index.html      # → entrée de l'app admin
ls apps/docs/build/index.html               # → page entrée de la doc

Variables d'environnement de l'API​

L'API exige les variables suivantes au démarrage. La validation est stricte (Zod) : l'app refuse de démarrer si une variable manque.

PORT=3000
DATABASE_URL=postgresql://user:pwd@host:5432/dbname
JWT_SECRET=<aléatoire ≥ 32 caractères>
JWT_ACCESS_EXPIRES_IN=15m
JWT_REFRESH_EXPIRES_IN=7d
PAYMENT_PROVIDER=stub                # MVP : stub | (v1.1 : stripe, paystack...)
# REDIS_URL=redis://host:6379/0      # Décommenter quand Redis est en place
# REDIS_PREFIX=mombiz:

Génération du JWT_SECRET​

openssl rand -base64 48

Ne jamais réutiliser le secret de dev en prod. Stocker dans le secret manager du provider (Vault, Doppler, GitLab CI variables protégées).

Variables d'environnement du frontend​

Le frontend ne consomme qu'une variable à build time (VITE_API_URL) qui est inlinée dans le bundle :

VITE_API_URL=https://api.mombizacademy.com/api/v1

Le bundle généré est immuable : un changement d'URL d'API impose un re-build.

Pistes d'hébergement (roadmap)​

ComposantPiste évaluéeNotes
API + baseVPS Hetzner ou OVH (2 vCPU / 4 Go)Postgres et Redis dédiés sur le même VPS
FrontendVercel ou Cloudflare PagesStatic hosting + CDN, build via webhook GitLab
DocumentationGitLab Pages ou NetlifyBuild statique simple, redéploiement à chaque push
TLSCaddy ou Nginx + Let's EncryptAutomatique sur reverse proxy

Aucun choix n'est arrêté — la décision sera tracée comme ADR.

Contraintes prod​

  • Postgres et Redis dédiés (pas de mutualisation comme en dev)
  • Migrations Prisma : prisma migrate deploy uniquement (pas migrate dev qui crée une shadow DB)
  • CORS restreint au domaine du frontend de prod
  • Helmet + Throttler déjà activés au boot — pas de config supplémentaire requise
  • Backup base de données : automatisé en amont du déploiement (cf. Base de données)

Lancer en local le mode prod​

Pour tester un build prod sans déployer :

# Terminal 1 — API en mode prod
cd apps/api
node dist/main.js

# Terminal 2 — Les 4 frontends statiques derrière le reverse-proxy (cf. exemple Caddy ci-dessus)
#   public  → apps/frontend-public/dist   (/)
#   learner → apps/frontend-learner/dist  (/learner)
#   teacher → apps/frontend-teacher/dist  (/teacher)
#   admin   → apps/frontend-admin/dist    (/admin)

# Terminal 3 — Documentation
npm --workspace=@app/docs run serve

C'est utile pour détecter les bugs qui n'apparaissent qu'en mode optimisé (tree-shaking, mangling de noms, etc.).

Voir aussi​