framework

Croco Frameworkは、AWS LambdaとAPI Gatewayを第一級市民として扱うNode.jsベースのTypeScriptフレームワークです。READMEでは自らを「主観がはっきりした（opinionated）」フレームワークと紹介しており、大規模プロジェクトでアーキテクチャの一貫性を維持することが困難であるという問題意識から、役割別のパッケージ境界を明示的に分けています。 パッケージは、Kernel（フレームワークランタイム基盤：framework-context, framework-module）、Contracts（プロバイダー・ランタイム独立のドメイン/プロトコル契約：repository-core, protocols-rest, telemetry-api）、Plugins（契約の実装と環境バインディング：tx-drizzle, transports-http, preset-node）、Application（アプリ所有モジュールとcomposition root）、Profiles（検証済みのplugin/module組み合わせ：presentation-preset）、Tooling（build, codegen, testing, CLI）の6つの役割に分類されます。KernelとContractsは具体的なPluginに依存せず、ドキュメントによると役割の基準情報はdocs/package-catalog.jsonのpackageRolesに基づいています。 Host・Transport・Build Targetを区別している点が特徴です。HostはNode process/server、Lambda invocation、Workers fetchのライフサイクルを所有し（preset-node, preset-lambda, preset-cloudflare）、TransportはHTTP・GraphQL・RPCなどのプロトコル表面を実行し、Build Targetはentrypoint・出力ディレクトリ・module format・バンドリング制約を宣言するTooling契約です。1つのHostが複数のTransportコールバックをバインドできます。 機能としては、DDDドメインイベント（events-core）とRegisterEventHandler、Unit of Work方式のTransactionalトランザクション（tx-core, AsyncLocalStorage伝播）、RFC 7807ベースのProblem応答による問題の詳細化（problems-core）、リトライ・復旧デコレータ（Retryable, Recover — retry-core）、OpenTelemetry Spanを生成するTrace（telemetry-api）、デコレータベースのDIコンテナ（framework-context）を提供します。RESTコントローラーはController/Get/Postデコレータで定義し、createAppとcreateLambdaHostでLambdaハンドラーを構成します。 SaaSドメインをターゲットに、ビリング・エンタイトルメント・クレジット・メータリング・顧客状態などの契約パッケージと、Polar, Clerk, Drizzle, PostHog, QStashなどのプロバイダー・統合パッケージが共に提供されます。ドキュメントでは、失敗を一般的なErrorやsilent fallbackで隠さず、Problem, retry, timeout, circuit breaker, idempotency, exhaustive handlingでモデリングすることを原則として掲げています。 開始手順はnpx create-croco-app@latestでスキャフォールディングし（例：--goal saas-api）、pnpm demo:smokeで外部認証情報なしに生成されたREST契約とインメモリSaaSフローを検証する方法であり、examples/quick-start-lambdaでAuthとMeteringを含む例をpnpm devで実行できます。ルートAはドキュメントベースのスキャフォールドガイド、ルートBは完成例の実行です。 READMEによると、カタログはパブリックパッケージ120個を追跡し（非公開2個を除く）、1.0 spineで18個のパッケージをrelease-criticalな互換範囲に固定しています。そのうち10個はproduction-ready、8個はbetaであり、alpha/WIPおよびdeprecatedは0個です。成熟度・グループ情報はリポジトリメタデータから生成される成果物であり、ドリフトが発生するとdocs:catalog:checkが失敗すると説明しています。ベンチマークはbenchmarks/ディレクトリで方法論・ベースライン・閾値を管理し、専用ワークフローで直近5回のgreen evidenceに基づきblocking gateとして動作すると記述されていますが、具体的な性能数値はREADMEに提示されていません。NestJS・Hono・tRPCとの比較表についても、性能数値や競合評価ではなく、設計中心の違いを説明するためのものであると明記しています。