パフォーマンスとスケール は何をしますか？
概要
パフォーマンスは予算のある機能です。測定し、制限し、今日の振る舞いが明日の契約になることを尊重してください。システムは、設計したスループットでダウンすることはめったにありません。インデックスを張っていないクエリや、ページネーションを実装していないリストでダウンします。
原則
- 予算を設定し、それに対して測定する。 レイテンシ目標（
observability-and-slosのSLOに紐づく）とクライアント予算（例：バンドルサイズ）。予算を超える回帰はバグです。 - 最適化する前に測定する。 データ（プロファイル、クエリプラン、トレース）を使って実際のボトルネックを見つけてから、コードを変更してください。推測による最適化は禁止です。
- デフォルトでページネーションを実装する。 増加する可能性のあるリストはすべて、上限付きのページサイズでページネーションします。無制限の結果セットはレイテンシとサービス拒否の危険をもたらします。
- N+1アクセスパターンに注意する。 ループ内でデータを取得することは、最も一般的なスケーラビリティ障害です。代わりにバッチ処理か結合を使用してください（このスタックでは、行ごとの解決ではなく、GraphQLレイヤーの先行読み取り/DataLoaderを使用します）。
- ハイラムの法則は現実です。インターフェースの観察可能な振る舞いは、十分な数のコンシューマーがいる場合、そのすべてが誰かの依存契約になります。 これには、意図していなかった振る舞い（順序、null可能性、エラー形状、タイミング）も含まれます。公開インターフェース（特にAPI/スキーマ）は契約として扱ってください：サイレントに変更するのではなく、追加と非推奨化を行ってください。
graphql-contract-testingの契約テストは、あなたが選択した振る舞いを固定します。規律は、あなたが選択しなかった振る舞いを保護します。
クイックリファレンス
| 悪臭（スメル） | 修正方法 |
|---|---|
| ループ内のクエリ | バッチ処理または結合、先行読み取りを使用 |
| 制限のないリストエンドポイント | 上限付きページネーションを追加 |
| 「測定なしで最適化させてくれ」 | 最初にプロファイル、本当のボトルネックを見つける |
| フィールドの型/null可能性/順序の変更 | 契約の変更 — 新しいものを追加し、古いものを非推奨化 |
| レイテンシやバンドル目標がない | 予算を設定し、回帰をバグとして扱う |
実施方法（エンフォースメント）： 機械化可能なものはCIで予算をチェック（バンドルサイズ制限、クエリコスト制限）。ページネーションとN+1回避は、負荷テストとクエリプランレビューに基づくレビューアの判断に委ねられます。
完全な根拠：憲法第11条、engineering-constitution/references/engineering-constitution.mdにバンドルされています。