Architecture on vanityURLs

Les décisions d'architecture vivent avec le code

Tue, 26 May 2026 00:00:00 +0000

Une page de setup devrait dire à l’opérateur quoi faire.

Elle ne devrait pas porter toute l’histoire du Worker, de l’installateur, du schéma, de l’automatisation de release et des règles de sécurité runtime. Cette histoire reste importante. Elle appartient pres de l’implementation.

vanityURLs garde les décisions produit dans des architecture décision records dans le dépôt code. Les docs publiques restent opérationnelles. Le dépôt code garde le raisonnement dont les futurs mainteneurs auront besoin lorsque le prochain changement semble évident, mais ne l’est pas.

Du fichier de redirections au runtime Worker

Fri, 15 May 2026 00:00:00 +0000

vanityURLs a commence avec une idee volontairement petite : un domaine court, un fichier texte, et des redirections relues dans Git.

Cette première version était importante parce qu’elle prouvait le principe central. Un raccourcisseur de liens n’a pas besoin d’être une plateforme louee a quelqu’un d’autre. Il peut être une infrastructure que vous possèdez.

La première forme

La première implementation s’appuyait sur Cloudflare Pages et un comportement de redirection statique. C’était suffisant pour des alias simples, mais les limites sont vite apparues :

L'architecture v8s actuelle

Fri, 15 May 2026 00:00:00 +0000

La release v8s actuelle repose sur un contrat simple : garder le runtime petit, garder la source de vérité dans Git, et pousser le filtrage d’abus aussi pres de l’edge que possible.

Le modèle d’instance

Une instance a deux types de fichiers :

defaults/ contient les defaults du produit, les pages opérationnelles publiques, les defaults de blocklist, les consignes robots et crawlers LLM, et les scripts qui doivent être mis à jour depuis upstream
custom/ contient les liens propres à l’instance, les planifications, le remplacement de politique, l’habillage, les pages légales, et les fichiers publics volontairement locaux

Cette séparation est l’histoire de mise à jour. Si les propriétaires gardent leur travail dans custom/, les futures releases peuvent rafraichir defaults/ et scripts/ sans écraser le contenu local.