À propos du projet

Croco Framework est un framework TypeScript basé sur Node.js qui considère AWS Lambda et API Gateway comme des citoyens de première classe. Le README le présente comme un framework « opinionné », définissant explicitement des frontières de packages par rôle pour maintenir la cohérence architecturale dans les projets de grande envergure. Les packages sont classés en six rôles : Kernel (base du runtime : framework-context, framework-module), Contracts (contrats de domaine/protocole indépendants du fournisseur : repository-core, protocols-rest, telemetry-api), Plugins (implémentations et liaisons d'environnement : tx-drizzle, transports-http, preset-node), Application (modules propriétaires et composition root), Profiles (combinaisons validées de plugins/modules : presentation-preset) et Tooling (build, codegen, testing, CLI). Le Kernel et les Contracts ne dépendent d'aucun Plugin spécifique, et les informations de référence des rôles se trouvent dans packageRoles au sein de docs/package-catalog.json. Le framework se distingue par la séparation entre Host, Transport et Build Target. Le Host gère le cycle de vie (Node process/server, Lambda invocation, Workers fetch via preset-node, preset-lambda, preset-cloudflare), le Transport exécute les surfaces de protocole comme HTTP, GraphQL ou RPC, et le Build Target est un contrat de Tooling déclarant le point d'entrée, le répertoire de sortie, le format de module et les contraintes de bundling. Un seul Host peut lier plusieurs callbacks de Transport. En termes de fonctionnalités, il propose des événements de domaine DDD (events-core) avec RegisterEventHandler, des transactions de type Unit of Work (tx-core, propagation via AsyncLocalStorage), une spécification des réponses d'erreur basée sur la RFC 7807 (problems-core), des décorateurs de tentative et de récupération (Retryable, Recover — retry-core), le traçage Trace générant des Spans OpenTelemetry (telemetry-api), ainsi qu'un conteneur DI basé sur des décorateurs (framework-context). Les contrôleurs REST sont définis via les décorateurs Controller/Get/Post, et le handler Lambda est configuré avec createApp et createLambdaHost. Ciblant le domaine SaaS, il fournit des packages de contrats pour la facturation, les droits (entitlements), les crédits, le metering et l'état client, ainsi que des packages d'intégration pour des fournisseurs tels que Polar, Clerk, Drizzle, PostHog et QStash. La documentation stipule que les échecs ne doivent pas être masqués par des erreurs génériques ou des fallbacks silencieux, mais modélisés via Problem, retry, timeout, circuit breaker, idempotency et exhaustive handling. Pour débuter, le scaffolding se fait via npx create-croco-app@latest (ex: --goal saas-api), et pnpm demo:smoke permet de valider les contrats REST et les flux SaaS en mémoire sans identifiants externes. Un exemple incluant Auth et Metering est disponible dans examples/quick-start-lambda via pnpm dev. Selon le README, le catalogue suit 120 packages publics, avec 18 packages fixés dans la portée de compatibilité release-critical du « 1.0 spine ». Parmi eux, 10 sont production-ready et 8 sont en beta. La maturité et les informations de groupe sont des produits générés à partir des métadonnées du dépôt ; toute divergence entraîne l'échec de docs:catalog:check. Les benchmarks sont gérés dans le répertoire benchmarks/ avec des méthodologies et des seuils spécifiques, servant de blocking gate basé sur les 5 dernières preuves positives (green evidence) dans un workflow dédié, bien qu'aucun chiffre de performance précis ne soit mentionné dans le README. Le tableau comparatif avec NestJS, Hono et tRPC est précisé comme servant à expliquer les différences de conception plutôt qu'à fournir des mesures de performance ou des évaluations concurrentielles.