Statique d'abord

Le site public de Chinaski est du HTML statique simple servi depuis le disque, et la base de données n'est touchée que pendant que vous rédigez du contenu. Cette page explique pourquoi il est construit ainsi et ce que cela signifie pour votre travail quotidien.

Comment votre site est réellement livré

Chinaski tourne comme deux pièces coopérantes :

Le CMS: une application d'admin privée où vous écrivez et organisez le contenu. Elle stocke tout dans une base de données intégrée et livre l'interface d'admin du site.
Le builder: un processus séparé qui lit cette base, rend vos pages à travers des templates, et écrit de simples fichiers HTML statiques sur disque.

Votre serveur web sert ces fichiers statiques directement. L'application CMS n'est jamais dans le chemin des requêtes publiques. Dans le déploiement d'origine, les hôtes publics sont des serveurs de fichiers statiques, et la configuration serveur appuie cette architecture. Elle sert le répertoire de sortie généré depuis le disque, avec une exception étroite décrite ci-dessous.

Pourquoi c'est statique, pas dynamique

Comme le site publié n'est que des fichiers :

Aucun traceur ne peut se glisser dedans. Rien ne s'exécute sur le site public par défaut, et il n'existe aucun mécanisme qui pourrait injecter un beacon dans vos pages.
La surface d'attaque reste petite. L'application d'admin tourne liée à une adresse loopback (localhost uniquement), pas à une interface publique.
Rien à fuiter. La base de données (contenu, comptes, brouillons) vit côté rédaction et n'est pas exposée aux requêtes publiques.

Les builds sont explicites

Enregistrer ou publier du contenu ne reconstruit pas automatiquement le site. Un build est déclenché quand vous en démarrez un depuis le dashboard d'admin, via un webhook configuré, ou en exécutant le builder vous-même. Les builds sont des opérations délibérées avec un journal visible, pas des effets de bord en arrière-plan. Chaque build est consigné pour que vous puissiez revoir exactement ce qui a été écrit.

Un seul build tourne à la fois ; un second déclenchement signale que le build est déjà en cours plutôt que de faire la course. Les builds sont incrémentaux par défaut, avec un rebuild complet disponible au besoin.

Le site ne tombe jamais pendant une mise à jour

L'écriture de la sortie est délibérément défensive :

Les fichiers sont écrits atomiquement : le nouveau contenu est mis en scène puis renommé en place, si bien que le serveur public ne sert jamais un fichier à moitié écrit.
Si le build échoue ou expire, le site précédemment construit reste en ligne, intact et non touché.
Avant qu'un nouveau build ne passe en ligne, le builder le compare au dernier bon build. Si quelque chose s'est mal passé (chute soudaine du nombre de pages, pic compté de liens cassés), le builder refuse de le promouvoir et le site précédent continue de servir. Une sortie périmée est le pire cas, pas une sortie cassée.
Les builds sont plafonnés à un budget d'écriture de 2 GiB, avec nettoyage automatique pour qu'un débordement avorte le build plutôt que de remplir le disque.

L'unique exception : les formulaires

Comme le site public est statique, les soumissions de formulaires ne peuvent pas être gérées par le serveur de fichiers. Cela affecte les formulaires des blocs de contact et de newsletter : les soumissions POST vers /forms/<the form's address>, que le serveur web proxifie vers l'application CMS. La configuration du déploiement d'origine inclut ce proxy ; le retirer n'est sûr que si le site n'a pas de formulaires.

Les pages protégées par mot de passe sont aussi statiques : le contenu protégé s'embarque dans le fichier HTML et est déverrouillé dans le navigateur du visiteur par une vérification de mot de passe. Cela signifie que le contenu est techniquement présent dans la page même tant que le garde est verrouillé ; un visiteur qui lit le HTML brut peut l'en extraire.