ADR 028 — 2e workload supply chain : frontend SPA conteneurisée (2026-06-30)

Statut

Accepté — vertical slice V1 validée live le 2026-07-02 (#110). Acte les décisions d'architecture de l'issue #109 (build + CI + image scannée). La couche code/Dockerfile est livrée en MR2 (#109), le déploiement GitOps + routing en #110.

Contexte

Le projet n'expose qu'un seul workload applicatif (l'API FastAPI). Ajouter un frontend sert deux objectifs : un 2e workload pour démontrer la supply chain de bout en bout (build hardened, scan, ECR dédié, GitOps) et une UI qui consomme l'API.

L'angle est 100 % DevOps : le contenu React est volontairement trivial. La valeur démontrée est la chaîne, pas l'applicatif. On veut donc une plateforme solide dès le départ (V1) et un contenu qui peut évoluer ensuite (V2) sans retoucher la chaîne DevSecOps.

Décision

Stratégie V1 / V2 (walking skeleton)

• V1 = #109 + #110 : la vertical slice n'est prouvée que live de bout en bout (image scannée → déployée → URL qui répond). #109 seul livre la moitié supply-chain (candidate dans ECR), #110 ferme la slice (deploy GitOps + routing). Validé live le 2026-07-02 : app.devopsyouss.com sert la SPA qui fait un fetch cross-origin vers api.devopsyouss.com/posts/public, CORS strict (origine app. autorisée, toute autre refusée), le feed s'affiche. Détail : incidents/sprints/sprint5.md.
• V2 = enrichissement du contenu React uniquement, sans toucher l'infra ni le back.
• Garantie que V2 ne touche pas la chaîne = figer trois invariants en V1 :
• Origine de la SPA : sous-domaine app.devopsyouss.com (cohérent avec api./grafana./argocd., couvert par le cert wildcard *.devopsyouss.com, CNAME auto ExternalDNS, Gateway allowedRoutes: All). Choix figé maintenant pour ne jamais avoir à changer d'origine après coup (un changement d'origine = ajout/retrait CORS côté FastAPI + refonte du routing = modification de la chaîne). Implémenté en #110.
• CORS : CORSMiddleware FastAPI restreint à https://app.devopsyouss.com (least-privilege, pas *), lecture seule pour démarrer. Posé en #110.
• Contrat API : la SPA ne consomme que des endpoints déjà existants (/posts, lecture seule, public en V1). Tout nouvel endpoint redeviendrait du back, hors V2.

Runtime = nginx-unprivileged

Image runtime nginxinc/nginx-unprivileged (pinnée par digest), uid 101 non-root, écoute sur le port 8080 (non privilégié), fallback SPA try_files $uri $uri/ /index.html. Standard industrie pour servir des assets statiques, compatible runAsNonRoot / readOnlyRootFilesystem, défendable en entretien. Dockerfile multi-stage : node (build Vite) → nginx-unprivileged (runtime), seuls les assets compilés passent dans l'image finale (pas de toolchain Node en production).

Monorepo

Le frontend vit dans frontend/ du repo existant (pas de nouveau dépôt). Le trivy-fs-scan de la CI scanne déjà . à la racine → frontend/package-lock.json est ramassé automatiquement (pas de job de scan deps front à créer). Un seul dépôt, une seule CI, deux workloads.

ECR isolé (2e instance du module)

Un repository ECR dédié au front (fastapi-eks/frontend), séparé du back (fastapi-eks/fastapi), pour isoler les cycles de vie d'images (lifecycle, scan, rétention). Réalisé en instanciant le module ecr une 2e fois (paramètre repo_suffix), plutôt qu'un refactor for_each risqué sur une ressource ECR contenant les images deployed- servies (tout destroy/replace = ImagePullBackOff). Le renommage interne de la ressource (.fastapi → .this) est fait via des blocs moved {} = renommage d'état, zéro destroy/replace sur le repo back existant.

Conséquences

• Le module ecr devient réutilisable : module.ecr (back) + module.ecr_frontend (front), même lifecycle policy à 3 règles (ADR 021), même politique de pull EKS.
• Au terraform apply persistent : 1 ressource créée (module.ecr_frontend), 0 destroy/replace sur le back (les moved couvrent le renommage ; seul le tag Name du repo back est mis à jour in-place, sans recréation).
• La chaîne CI (jobs build-frontend-candidate + trivy-frontend-image-scan) et le déploiement (#110) consomment ce repo. Le promote deployed- / write-back GitOps front est traité en #110.
• V2 (enrichissement React) ne touche ni Terraform, ni CI, ni back tant que les 3 invariants tiennent.

Alternatives écartées

• Path-based, même origine (app.devopsyouss.com/ front + /posts back sur le même host) : éviterait CORS, mais forcerait à réorganiser la rule HTTPRoute / du back (qui attrape tout, cf #81) → collision de routes, plus risqué. Le sous-domaine réutilise un pattern déjà rodé (grafana, argocd).
• Refactor for_each du module ECR : élégant mais à risque sur un repo persistant contenant les images servies (mauvaise clé d'index = destroy/recreate = ImagePullBackOff). Le 2e appel de module est plus sûr.
• Dépôt Git séparé pour le front : ajouterait une 2e CI, un 2e cycle de release, pour un contenu trivial. Le monorepo garde une seule chaîne.
• Image runtime nginx standard (root) : tourne en root, écoute sur 80 privilégié, incompatible avec un durcissement runAsNonRoot propre.

Validation

• Hors infra (MR1) : terraform fmt/validate, tfsec (0 HIGH, image CI exacte sur copie propre, INC-049), mkdocs build.
• Live (clôture #109) : terraform apply persistent → plan = 1 add (ecr_frontend), 0 destroy/replace sur ecr ; puis push develop → build-frontend-candidate + trivy-frontend-image-scan verts, candidate front poussée dans fastapi-eks/frontend.

Addendum V2 — authentification frontend (#128, 2026-07-03)

Recadré le 2026-07-02 (décision Youssef) : la V2 initialement prévue Sprint 6 est avancée au Sprint 5. Contenu : login, register, création de posts, votes depuis la SPA — sans toucher la chaîne DevSecOps ni les 3 invariants ci-dessus. Vérifié avant code que tout tient dans les endpoints existants : POST /users/ (public), POST /login (form-urlencoded), POST /posts/ (Bearer), POST /votes/ (Bearer), GET /posts/public (pagination + recherche déjà servies), CORS allow_methods:*/allow_headers:*. Zéro changement back/infra → promesse V1/V2 tenue.

Stockage du JWT : mémoire + sessionStorage

• Écarté : cookie httpOnly. Le plus sûr contre XSS, mais exige un changement back (réponse Set-Cookie, protection CSRF) — sort de la promesse « V2 = React uniquement ».
• Écarté : localStorage. Persiste au-delà de l'onglet/fenêtre sans bénéfice pour une démo portfolio ; surface XSS identique à sessionStorage mais durée de vie plus large.
• Retenu : état React (source de vérité pour les rendus) + copie sessionStorage (survit à un F5, pas à la fermeture de l'onglet). Compromis assumé pour un projet de démonstration, pas pour une prod avec des données sensibles.

Écriture publique assumée

POST /users/ (register) est déjà public côté API — la SPA ne fait qu'exposer un formulaire sur un endpoint existant, elle n'affaiblit pas la posture. Risque de spam documenté et accepté pour la démo (pas de CAPTCHA ni de vérification email) ; mitigation = #129 rate limiting Envoy, créée en backlog, hors scope #128.

Vote UI inclus

POST /votes/ (Bearer) déjà servi par l'API → bouton vote ajouté à la carte post (MR2), aucun nouvel endpoint requis. L'API ne renvoie aucun flag « j'ai voté » sur un post (ni dans PostOut, ni ailleurs) : impossible de savoir au chargement du feed si l'utilisateur courant a déjà voté. Retenu : l'état « voté » du client est déduit des réponses d'erreur de POST /votes/ — un 409 (vote déjà existant) confirme un vote, un 404 (rien à retirer) confirme l'absence de vote — plutôt que d'ajouter un champ côté back (hors promesse V1/V2). Conséquence assumée : cet état est local à l'onglet (pas persisté), un F5 réinitialise l'affichage « non voté » même si le vote existe toujours côté serveur (le compteur, lui, reste exact).

Découpage 3 MR hors infra

MR1 (#128, auth : login/register/token/logout) → MR2 (écriture : formulaire post + vote) → MR3 (lecture enrichie : pagination/recherche/détail client-side sur GET /posts/{id} authentifié). Chaque MR se valide en local (docker-compose-dev, cross-origin localhost:3000 → localhost:8080), la chaîne CI/scan/GitOps est inchangée.

MR1 (auth) : frontend/src/api.js (fetch purs login()/register(), contrat form-urlencoded vs JSON respecté), frontend/src/auth.js (sessionStorage), frontend/src/AuthForms.jsx (panneau connexion/inscription). Pas d'auto-login après inscription (/users/ ne renvoie pas de token) : retour à l'onglet connexion. Validé : build Vite OK, Trivy 0 CVE, flux réel register→login→JWT testé via docker-compose-dev (curl direct API + vérification du préflight CORS depuis localhost:3000), bundle JS servi contient le code auth.

MR2 (écriture) : frontend/src/api.js étendu (authFetch() interne portant le header Authorization: Bearer, createPost(), castVote() — les erreurs portent le status HTTP pour que l'appelant distingue un 409/404 d'une vraie panne), frontend/src/PostForm.jsx (formulaire titre/contenu, visible uniquement connecté), App.jsx (bouton vote interactif par post, votedPostIds en état local). La réponse de POST /posts/ (schemas.Post, owner déjà résolu par la relation SQLAlchemy) est ré-emballée côté client au format { Post, votes: 0 } de /posts/public pour réutiliser le même rendu, sans re-fetch. Validé : build Vite OK, Trivy 0 CVE, cycle complet testé via docker-compose-dev (register→login→create post→vote dir=1→409 sur rejeu→vote dir=0→404 sur rejeu, contrat API confirmé exactement conforme au code), testé en direct par Youssef dans le navigateur (localhost:3000, logs confirmant un POST /votes/ 201 depuis Chrome).

MR3 (lecture enrichie) : frontend/src/api.js étendu avec fetchPublicPosts({ search, skip, limit }) (réutilise les paramètres déjà servis par /posts/public, aucun nouveau paramètre côté back) et getPostDetail(token, id) (GET /posts/{id}, Bearer). App.jsx ajoute une barre de recherche (soumission = rechargement de la page 1 avec le terme), un bouton « Charger plus » (skip avance de PAGE_SIZE=5 tant que la dernière page est pleine), et un panneau détail (un post créé localement via MR2 décale skip d'1 pour éviter un doublon lors d'un « Charger plus » ultérieur — mitigation best-effort, pas une garantie stricte sur un flux concurrent).

• Détail réservé aux connectés : GET /posts/{id} exige déjà Depends(oauth2.get_current_user) côté back (contrairement à /posts/public) — le bouton « Détail » n'est affiché que si auth est posé, cohérent avec le contrat existant plutôt qu'une restriction ajoutée côté front.
• Piège découvert en testant (pas en lisant le code) : GET /posts/{id} renvoie le même format PostOut que /posts/public ({ Post: {...}, votes }), pas un schemas.Post plat comme POST /posts/. Un premier essai accédait à detail.post.title directement → undefined silencieux (React n'aurait rien affiché, pas d'erreur bruyante). Corrigé après un test curl direct sur /posts/1 qui a révélé la vraie forme de la réponse.
• Pas de nouvelle page dédiée : le détail s'affiche dans un panneau au-dessus du feed (pas de routeur ajouté, cohérent avec l'absence de dépendance de routing dans le projet).

Validé : build Vite OK, Trivy 0 CVE, pagination/recherche/détail testés via docker-compose-dev (7 posts créés, limit=5&skip=0 → 5 résultats, skip=5 → 2 restants, search=Post%203 → 1 résultat, détail avec token → 200, détail sans token → 401 confirmant le gate back), testé en direct par Youssef dans le navigateur.

Addendum V3 — CRUD complet + habillage DevOps (#130, 2026-07-04)

Deux manques relevés pendant la validation live de la V2 (2026-07-04) : pas de modification/suppression de ses posts depuis la SPA, et le panneau détail affiché dans un bloc fixe en haut de page (peu lisible avec plusieurs posts). Comme pour la V2, tout tient dans les endpoints existants : PUT /posts/{id} et DELETE /posts/{id} (Bearer, owner-only : 403 si l'utilisateur n'est pas propriétaire) sont dans l'API depuis l'origine — zéro changement back/infra, promesse V1/V2 toujours tenue.

MR1 — edit/delete + détail inline

• frontend/src/api.js : updatePost() (PUT, body { title, content } identique à la création, published garde son défaut) et deletePost() (DELETE, 204 sans corps). La réponse du PUT est un Post plat sans garantie sur la relation owner : le client fusionne title/content dans l'item déjà affiché au lieu de remplacer l'objet (même leçon que le wrapper PostOut de la V2 MR3 : ne pas se fier à la forme supposée d'une réponse).
• Ownership côté client = affichage seulement : les boutons Modifier/Supprimer ne sont rendus que si owner.email === auth.email, mais c'est l'API qui fait autorité (403 rejoué côté serveur sur PUT/DELETE). Le front ne peut pas affaiblir la posture.
• Suppression confirmée (window.confirm natif : zéro dépendance, pattern suffisant pour une démo) ; le retrait du post décale le curseur de pagination (symétrique de la création).
• Détail inline : le panneau se rend sous le post cliqué (re-clic = repli), plus de bloc fixe en haut de page. Édition inline de même : le formulaire pré-rempli remplace le contenu de la carte le temps de l'édition.

MR2 — habillage DevOps (logos SVG inline + footer stack)

Logos de la stack (GitLab, ArgoCD, AWS/EKS, Kubernetes, Terraform, Grafana) embarqués en SVG inline dans le bundle — pas de CDN externe : zéro dépendance réseau au runtime, aucune requête tierce, surface supply chain inchangée (le scan Trivy couvre tout ce qui est servi). Footer « stack » cliquable vers les livrables du projet (repo GitLab, doc MkDocs, Grafana, API). La page étant la carte de visite du projet en entretien, cet habillage sert le portfolio autant que l'esthétique.