GraphQL バリデータ
GraphQL スキーマの構文問題をチェックし、型・フィールド・enum・ディレクティブの内訳を確認
入力
検証
GraphQL バリデータとは？
フェデレーション コンポーザーやコード ジェネレーター、コードレビュー中の手作業の編集から戻ってきたスキーマには、最初の処理時点でほぼ必ず構文の問題が少なくとも 1 つあります。余分な }、終端のない説明文字列、誰かが SDL の半画面分をチャットにコピペしたときに切れた enum の本体 — そして気がつくと Apollo Server の起動が 1 行目を指すパーサーエラーで吹き飛ぶのですが、そこは実際の問題のある場所ではないことがほとんどです。このバリデータは SDL をトークン単位で歩き、本当の行を指し示します。
2021 年 10 月版 GraphQL 仕様 の構造的なルールをチェックします。すべての {、(、[ は同じ種類の閉じカッコが必要、"""...""" として書かれた説明は終端させる必要があり、引数内のクォート文字列は同じ行で閉じる必要があります。バリデータは意味論を検証 *しません* — Query が欠けていることや、フィールドが宣言されていない型を参照していることは教えてくれません。それには参照実装の graphql-js にスキーマを通してください。このページが得意なのは構文パスと統計ブロックなので、貼り付けたスキーマが 14 個の型なのか 4 個なのか、187 フィールドなのか 12 フィールドなのかが一目でわかります。
すべてはブラウザ内で動きます。アップロードなし、スキーマはどこにも保存されません。貼って、検証して、コピー。
GraphQL バリデータの使い方
簡単な 3 ステップです。下のボタンはこのページの実際のボタンと一致しています。
貼り付け、アップロード、またはサンプルの読み込み
左の 入力 パネルに GraphQL スキーマを貼り付けてください — 入力をやめてから 1 秒未満で検証が自動的に走るので、Validate ボタンはありません。.graphql、.graphqls、.gql ファイルなら アップロード をクリック、現実的な e コマースの Order スキーマを読み込みたいなら サンプル を押してください。典型的な貼り付けはこんな感じです：
type Order { id: ID! placedAt: DateTime! customer: Customer! items: [OrderItem!]! status: OrderStatus! } enum OrderStatus { PENDING PAID SHIPPED }サーバー形式のスキーマ（extend type Query を含むもの）も、スタンドアロンの型ファイルも動作します。コメント（#）とブロック文字列の説明（"""..."""）は、GraphQL の learn-schema ドキュメント が説明している通りに扱われます。
統計ブロックを読む
右側のパネルは、スキーマがきれいにパースできれば緑のバナー、できなければ赤のバナーを表示します — そしてどちらの場合でも、スキーマが宣言している type、interface、enum、input、union、scalar、directive の定義数の内訳に加えて、フィールド総数、引数数、説明数が得られます。フェデレーション マージの健全性チェックや、同じスキーマの 2 つのリビジョンの比較に便利です。カウントは、Relay の GraphQL 仕様 が定義の構造的な部品として呼ぶものを反映しています。
修正して貼り直す
スキーマが無効な場合、バナーが閉じカッコの不一致や終端のない文字列の正確な行を教えてくれます。直して、貼り直して、バナーが緑になるのを見届ける。右側のコピー ボタンを押すと、PR の説明やチャット メッセージに貼り付けられる小さな JSON 統計レポートが取れます — SDL 自体を共有せずに、同僚に「うん、スキーマは問題ないよ、これが統計」と見せたいときに便利です。
実際にこれを使う場面
マージ前の健全性チェック
フェデレーション ゲートウェイの変更や schema-stitching の更新をマージする前に、合成されたスキーマをここに貼り付けてください。カッコのバランスがずれていたり、説明が終端していなければ、10 分後の CI 失敗ではなく 2 秒でわかります。意味論面では rover subgraph check コマンドと組み合わせるとよいです。
2 つのリビジョンの差分
バージョン A を貼って、統計の数値（28 型、142 フィールド、6 enum）をメモする。バージョン B を貼って比較。フィールド数が 40 も増えているのに新しい型が 1 つだけなら、誰かがフラグメントを重複させた可能性が高いです。統計ブロックは 2000 行の差分をスクロールするよりずっと速いです。
新しい外部開発者のオンボーディング
スキーマ ファイルを渡し、このページに案内し、「赤くなれば貼り付けが壊れている、フィールド数が突然 800 少なくなれば、半分しかコピーしていない」と伝えてください。リゾルバーを書き始める前の「これで全部？」という往復のやり取りを省けます。
チャットからの貼り付け
Slack と Discord は長いメッセージを折り返すときにバッククォートやクォート文字を壊すのが大好きなので、スレッドに貼られたスキーマは閉じカッコを 1 つや 2 つ失っていることがよくあります。IDE で開く前に、まずここに入れて確認しましょう。
よくある質問
意味論を検証しますか、それとも構文だけですか？
構文だけです — カッコのバランス、文字列の終端、トークン ストリームに対する統計的な走査です。Query が存在するか、参照されている型が定義されているか、引数がディレクティブ定義に一致するか、フィールド型が有効かは *チェックしません*。完全な意味論検証には、参照ライブラリの graphql-js またはサーバー起動時のチェックを使ってください。
スキーマはサーバーに送信されますか？
いいえ。検証は完全にブラウザ内で実行されます。アップロードもログ記録もありません。社内のスキーマや未公開のスキーマを貼っても安全です。
実際にどんな構文の問題を捕まえてくれますか？
対応していない { / ( / [ とその開きカッコの行番号、} が期待されている場所の ) のような誤った閉じカッコ、終端のない "strings" や """block strings"""、GraphQL のトークン文法の一部ではない迷子の文字です。
型が明らかにあるのに、なぜスキーマには 0 型と表示されますか？
統計カウンターは、定義のキーワード（type、interface など）AND 本体の波カッコの両方が揃って初めてその定義をカウントします。途中で切れたスキーマを貼った場合、本体を完成させるまでその型のカウントは 0 のままです。その場合バリデータのバナーも赤くなり、対応していない開きカッコを指し示します。
ブロック文字列の説明を理解しますか？
はい。"""An order placed by a customer.""" は説明トークンとして認識され、Descriptions 統計でカウントされます。説明をどこに置くかはバリデータでは強制しません — それはスタイルの選択です — が、カウントによってスキーマがどれだけドキュメント化されているかをすばやく把握できます。
どれくらい大きいスキーマを貼れますか？
ブラウザが快適にレンダリングできるものなら何でも。数百の型と数千のフィールドのスキーマは 1 秒未満で検証されます。5 MB を超えると Ace エディタ自体が遅くなり始めます — ボトルネックはバリデータではなくそちらです。
その他の GraphQL ツール
検証は GraphQL を扱う作業の一部に過ぎません。残りはこれらのツールが対応します：