go-performance-starter

Go Performance Starter est un point de départ orienté serveur et opinioné pour les petits produits SaaS, combinant Go (Chi), les templates templ, HTMX avec Alpine.js, Tailwind CSS, Supabase (Auth + PostgreSQL) et Cloudflare. Son pari est le rendu serveur via Go avec un minimum de JavaScript, où les budgets de performance et les garde-fous pour agents IA sont appliqués dans la CI plutôt que simplement décrits. Ce qu'il propose L'authentification utilise l'email/mot de passe de Supabase avec validation JWT côté serveur, et supporte également la connexion anonyme pour que les visiteurs de démo reçoivent une identité réelle sans s'inscrire. Le multi-tenancy repose sur la Row Level Security (RLS) de PostgreSQL : les revendications JWT de la requête sont transportées dans chaque requête via une transaction scoped (SET LOCAL ROLE plus request.jwt.claims), sehingga auth.uid() est résolu à l'intérieur des politiques RLS et la couche repository ne peut pas ignorer le scoping du tenant. Le README note que cela rend Supabase structurel plutôt qu'un adaptateur interchangeable ; une authentification neutre vis-à-vis du fournisseur nécessiterait de réécrire le middleware d'authentification, l'assistant de scope RLS et les politiques. La démo incluse est destinée à exercer la pile : une section /patterns présentant chaque pattern HTMX/Alpine supporté avec démo live et source, et un quiz d'architecture dont les mauvaises réponses deviennent des flashcards sauvegardables par utilisateur, stockées comme des lignes protégées par RLS. Un job d'arrière-plan expire les invités inactifs via l'API admin de Supabase. L'outillage développeur couvre les templates templ typés compilés en Go, la génération de code sqlc avec un pattern repository, le rechargement à chaud via air, l'automatisation Taskfile, golangci-lint, les métriques Prometheus, la journalisation structurée avec log/slog, les health checks et la CI/CD. Un système de design basé sur les rôles utilise des tokens sémantiques tels que bg-surface et text-muted-foreground, avec un mode sombre qui inverse les tokens plutôt que les composants, et des vérifications CI contre les gris bruts et la dérive dark:. Budgets de performance Le README liste les budgets imposés : temps de réponse P95 inférieur à 100ms, taille du binaire inférieure à 20Mo, image Docker inférieure à 30Mo, mémoire en état stable inférieure à 128Mo, et démarrage inférieur à 500ms, validés par task test:performance et task test:binary-size. Développement assisté par agent Le projet livre une constitution IA stratifiée : CLAUDE.md contient les règles d'arrêt en cas de violation (halt-on-violation), tandis que .claude/engineering.md, workflow.md et stack.md portent les défauts d'ingénierie, le processus et les faits techniques. AGENTS.md est généré à partir de ces couches par task agents:build et la CI échoue en cas de dérive. Les fonctionnalités non triviales suivent un flux en trois passes : Architecte, puis Codeur, puis Réviseur. La seule définition du "done" est la barrière de qualité task ci (formatage, lint, tests de race, vérifications de dérive, taille du binaire, scan de vulnérabilités), que les agents doivent franchir sans abaisser les seuils. Les Architecture Decision Records (ADR) comportent chacun une section Enforcement mappant les règles aux vérifications. task check:adr exécute une suite déterministe qui vérifie les conséquences testables des ADR, incluant un scanner de secrets. Les vérifications commencent comme des avertissements et deviennent bloquantes après une période sans erreur ou une détection réelle. Deux hooks sont bloquants : un Stop-gate empêchant les agents de terminer un tour avec des tests échoués ou un bloqueur, et un garde PreToolUse empêchant les modifications manuelles des ADR existants, de AGENTS.md ou du code généré ; les deux possèdent des interrupteurs d'urgence. Le README indique quelles pièces sont structurelles et lesquelles sont amovibles, incluant des instructions pour élaguer entièrement la suite d'enforcement. Le fichier root versions.json est décrit comme un contrat de consommation public listant les versions fixées de la pile ; task versions:check échoue si une clé diverge de sa source dans le dépôt, et l'ajout de clés est autorisé tandis que leur renommage ou suppression constitue un changement majeur. Prise en main et portée Les prérequis sont Go 1.26+, Docker et Docker Compose, Task, et Node.js 20+. Le démarrage rapide couvre le clonage, la copie de .env.example, le démarrage de la base de données, l'exécution des migrations, la génération des types sqlc, l'installation des dépendances Go et npm, et le lancement du serveur de dev avec rechargement à chaud, servant par défaut sur le port 4000. Une configuration unique du template de réinitialisation de mot de passe Supabase est documentée. Les tâches disponibles incluent dev, ci, build, test, coverage, performance et binary-size checks, lint, build CSS, build d'image Docker et scan de vulnérabilités. Le projet est publié sous licence MIT.