Documentation / Le projet

Vision et objectifs

{% raw %}

Pourquoi Crabster ?🔗

Un générateur d'application « batteries included » produit, à partir d'un modèle de domaine, une application complète — persistance, API, sécurité, tests, conteneurisation, CI — au lieu d'une page blanche ou d'un squelette minimal. Plusieurs écosystèmes en ont un ; celui de Rust n'en a pas.

Les développeurs Rust qui veulent démarrer un service web de production doivent aujourd'hui assembler manuellement : framework web, ORM, migrations, authentification, validation, documentation OpenAPI, observabilité, conteneurisation — un travail répétitif, sujet à erreurs, et qui diverge d'un projet à l'autre.

Crabster vise à combler ce vide : un générateur qui produit du code Rust idiomatique, compilable, testé et prêt pour la production, à partir d'une description de haut niveau du domaine métier.

Principes directeurs🔗

1. Code généré = code possédé. Le code généré appartient entièrement au développeur : pas de dépendance runtime vers un framework "magique" propriétaire. Le code produit est du Rust standard, lisible, modifiable, et ne nécessite pas Crabster pour compiler ou tourner une fois généré.
2. Idiomatique avant tout. On ne calque pas mécaniquement les patterns Java/Spring (annotations, réflexion, injection de dépendances runtime). On choisit les patterns Rust adaptés : traits, macros procédurales (avec parcimonie), composition explicite, gestion d'erreurs par Result.
3. Convention over configuration, mais sans magie noire. Des choix par défaut raisonnables et documentés, avec la possibilité de personnaliser via des templates (mécanisme de blueprints, cf. Architecture technique).
4. Production-ready dès la génération. Un projet généré doit démarrer, avoir des tests qui passent, un Dockerfile fonctionnel, une CI, et des health-checks — pas un squelette à compléter à moitié.
5. Évolutif et incrémental. Crabster doit permettre d'ajouter ou de modifier des enregistrements sur un projet existant sans tout régénérer, via un mécanisme de fusion (voir Phase 11, en V2).
6. API-first, frontend différé. La V1 se concentre exclusivement sur la génération backend (API REST + persistance + sécurité + docs). C'est un choix assumé : livrer un cœur de générateur solide et bien testé avant d'ouvrir le chantier frontend, plutôt que de diluer l'effort. Voir ADR-0001 ci-dessous.
7. Communauté et extensibilité. La valeur à long terme vient de l'écosystème de blueprints (support NoSQL, Kubernetes, providers cloud spécifiques…), pas uniquement du cœur.

Ce que Crabster n'est pas🔗

• Pas un framework runtime. Crabster est un outil time-of-generation : une fois le code généré, la dépendance à crabster disparaît (à l'exception éventuelle d'un crate utilitaire partagé minimal, à évaluer).
• Pas (en V1) un générateur de frontend. Aucune génération Angular/React/Vue ni Rust/WASM en V1. L'API générée est documentée via OpenAPI, ce qui permet de brancher n'importe quel frontend, ou de générer un client depuis le contrat OpenAPI avec des outils tiers.
• Pas une plateforme low-code. Crabster ne remplace pas l'écriture de logique métier ; il génère l'infrastructure et le CRUD de base, le développeur écrit la logique métier spécifique.

Public cible🔗

• Équipes backend Rust qui démarrent un nouveau microservice ou une nouvelle API et veulent éviter de reconstruire l'infrastructure standard à chaque fois.
• Équipes venant d'écosystèmes où ce type d'outil existe déjà (Java, .NET, Node) et qui cherchent le même modèle mental en Rust : modélisation de domaine, puis génération.
• Développeurs solo / petites équipes qui veulent un point de départ solide et opinionated plutôt qu'un choix paralysant parmi des dizaines de frameworks Rust.

Objectifs mesurables (V1)🔗

• Générer, à partir d'un fichier CDL décrivant N enregistrements et leurs références, un projet Rust qui compile sans intervention manuelle.
• Le projet généré expose une API REST CRUD complète (pagination, filtrage, tri) pour chaque enregistrement, documentée en OpenAPI 3.
• Le projet généré inclut : authentification JWT, migrations de base de données versionnées, tests d'intégration exécutables (cargo test), Dockerfile et pipeline CI (GitHub Actions) fonctionnels.
• Temps entre crabster new et une API qui répond en local : moins de 5 minutes, hors temps de compilation initial de l'écosystème Cargo.

ADR-0001 — API-only en V1🔗

• Statut : accepté (2026-09-03).
• Contexte : couvrir backend et frontend d'emblée oblige à maintenir en parallèle plusieurs frameworks JS, dont les cycles de rupture pèsent lourd. Pour Crabster, deux options frontend existent (réutiliser React/Vue/Angular, ou générer du Rust/WASM via Leptos/Yew), chacune avec un coût d'investissement et de maintenance significatif.
• Décision : la V1 de Crabster ne génère aucun frontend. Elle se concentre sur un backend API-only robuste, avec une documentation OpenAPI de qualité permettant de brancher n'importe quel client.
• Conséquences : le chantier frontend est explicitement différé à la Phase 16 de la V2 ; le choix entre "réutiliser l'écosystème JS" et "frontend Rust/WASM natif" sera tranché à ce moment-là, avec les apprentissages de la V1 API-only en main. {% endraw %}