harness

Cratefield Harness est le cœur open-source sous licence MIT derrière Cratefield, un framework backend en Rust à partir duquel vous compilez votre propre backend. Le postulat est le suivant : chaque produit a besoin d'un backend et presque aucun ne devrait être construit de zéro ; c'est donc ce backend, une fois pour toutes. Vous choisissez des crates de modules, connectez des adaptateurs et déployez un Worker sans état avec sa propre base de données. Modèle de composition. Une entreprise déclare un constructeur Harness avec une identité d'entreprise, une URL publique et des origines CORS, ajoute des modules et sélectionne un runtime avec sa liaison de base de données, ainsi que des fournisseurs de mailer et de captcha. La compilation refuse un module qui nécessite un port que le runtime ne fournit pas, deux modules revendiquant la même table ou route, ou un module construit avec une version de contrat différente. Le template d'entreprise exécute la composition sous cargo test, donc toute erreur de configuration échoue avant le déploiement. Modules et ports. Un module est une crate implémentant un trait Module et est monté sur un chemin versionné par nom de module. Il déclare son nom, les ports requis, les migrations (SQL intégré via include_str!, dans un sous-ensemble accepté par SQLite et Postgres) et un routeur axum. Les modules ne touchent jamais aux liaisons fournisseurs, aux variables d'environnement ou aux clients fournisseurs ; ils demandent des ports tels que Database, Mailer, Captcha, RateLimiter, Signer et KeyValue, et les adaptateurs répondent. Selon le README, cette règle unique est ce qui permet de quitter Cloudflare en changeant simplement une crate de runtime. Crates incluses. La façade cratefield ; cratefield-core avec le trait Module, le constructeur Harness, les traits de port, les erreurs problem+json, le scope de requête, le bus d'événements et les templates ; cratefield-runtime-cloudflare ; des adaptateurs pour le mail Resend, le captcha Turnstile et SQLite via rusqlite ; les modules email-signup avec double opt-in, désinscription et export admin, et waitlist avec confirmation, position et codes de parrainage ; cratefield-secrets avec des secrets chiffrés par enveloppe via le port Database ; cratefield-kms pour l'enveloppement et le déballage des clés de données, avec un fournisseur de fichier local qui refuse la production ; cratefield-ui, qui rend la surface du module en HTML sur /ui ; cratefield-cli exposant le binaire fz avec les commandes collect migrations, doctor et modules ; et cratefield-testing, un kit de conformité que chaque module doit passer. Les crates prévues sont cratefield-adapter-postgres via sqlx et cratefield-runtime-native sur tokio. Migrations et requêtes. Les requêtes passent par sea-query afin d'être rendues pour n'importe quelle base de données. Les liens de confirmation et de désinscription sont des jetons signés HMAC avec rotation de clé, il n'y a donc pas de magasin de sessions. Le scope de requête voyage dans les extensions axum plutôt que dans un état partagé, et le kit de conformité inclut un test de requêtes concurrentes pour le vérifier. Montage. Un module est soit compilé dans le Worker, ce qui est le défaut, soit exécuté comme un sidecar avec son propre Worker construit et déployé séparément et monté sur le même chemin via une liaison de service avec la même base de données et les mêmes secrets. Le README précise que l'option sidecar est conçue mais pas encore construite. Observabilité. Un span structuré par requête transporte request_id, method, route, module, status, duration_ms, ip_hash et ua_family, et jamais d'adresse email. Workers Logs est activé dans le template wrangler.toml et les réponses renvoient x-request-id. La taxonomie des erreurs est générée à partir du registre core et vérifiée pour détecter les dérives en CI. Feuille de route telle qu'indiquée dans le dépôt. M0 fondation (outils de workspace, core, runtime Cloudflare, adaptateurs Resend et Turnstile, adaptateur SQLite, fz, kit de test), M1 premiers modules, M2 première entreprise en ligne avec publication sur crates.io, docs et versionnage des contrats (marqué en cours), et M3 portabilité auto-hébergée avec l'adaptateur Postgres, le runtime natif, la suite de parité et le transfert de données. Trois autres épopées sont spécifiées mais non planifiées. Chaîne d'outils et statut. Rust Stable fixé dans rust-toolchain.toml, cible wasm32-unknown-unknown, worker-build et wrangler ; la CI exécute fmt, clippy avec interdiction des avertissements, les tests, cargo deny, et construit l'entreprise d'exemple en wasm pour qu'une dépendance native seule ne puisse s'immiscer dans un module. Les crates ne sont pas encore publiées sur crates.io, le README conseille donc de dépendre du dépôt via git. Les crates privées sont marquées publish = false plutôt que de résider dans un dépôt séparé. Licence : MIT.