Construire armeltechfun : Décisions d’Architecture Full-Stack et Retour d’Expérience

1. Pourquoi je n’ai pas construit ce blog sur Astro

Mon premier réflexe pour ce blog a été Astro. Il ne livre aucun JavaScript par défaut et rend cette propriété difficile à casser par erreur - il faut activement faire entrer une île dans l’hydratation, donc un blog plein d’articles statiques reste statique presque par construction. Le plan initial était Astro pour le front, avec Payload CMS tournant comme un service conteneurisé séparé, communiquant via une API REST. Une séparation propre, deux choses faisant chacune un seul travail.

Le problème est apparu dès que j’ai vraiment regardé ce qui rend Payload intéressant. Ses véritables avantages - la Local API, qui permet aux Server Components d’interroger la base directement, sans passer par HTTP ; le panneau d’administration qui se monte à l’intérieur de votre propre app plutôt que de vivre sur un sous-domaine séparé ; l’édition en contexte en direct - tout cela n’existe que lorsque Payload tourne dans le même processus Node que le front. En le faisant tourner comme service séparé, on obtient un CMS headless tout à fait correct parlant REST, ce qui est bien, mais ce n’est pas ce pour quoi on paie la complexité de Payload.

J’ai donc renoncé à la propreté deux-services-un-travail-chacun et je suis passé à Next.js App Router avec Payload embarqué dans le même processus - un seul codebase, un seul déploiement, un seul runtime à sécuriser au lieu de deux. Je n’ai pas totalement abandonné le réflexe zéro-JS ; j’ai simplement accepté qu’il demande désormais de la discipline plutôt que d’être acquis gratuitement. Des Server Components par défaut, et garder `use client` hors du corps des articles en particulier, couvre l’essentiel du chemin. C’est une décision que je dois reprendre à chaque pull request plutôt qu’une décision prise une fois dans un choix de framework - un vrai coût, mais que j’ai jugé valoir la peine pour ce que Payload m’apporte une fois embarqué.

2. Abandonner le backend FastAPI dont je n’ai jamais eu besoin

Le plan initial prévoyait aussi un service FastAPI séparé en Python, gérant les pourboires, l’inscription à la newsletter, le formulaire de contact et les compteurs de vues/engagement des articles - le genre de petites fonctionnalités avec état qui ne semblent pas évidemment appartenir à un CMS. J’ai commencé à l’ébaucher avant que la vraie question ne me frappe : qu’est-ce que FastAPI fait ici que Payload ne fait pas déjà ?

Payload est un framework backend complet, pas juste un modèle de contenu. Des collections, des règles de contrôle d’accès, des hooks qui s’exécutent à la création/mise à jour/suppression, des endpoints REST et GraphQL personnalisés, le tout contre la même base Postgres où vivent déjà les articles. Une inscription à la newsletter est une collection avec un champ email et un hook beforeChange qui appelle un fournisseur d’email. Une confirmation de pourboire est une collection avec un endpoint de création vérifié par webhook. Rien de tout cela n’avait besoin d’un second langage et d’un second runtime installés à côté de Next.js sans aucun bénéfice d’intégration - cela avait besoin de fonctionnalités que je pouvais construire directement dans le framework que je faisais déjà tourner.