Skip to content

MS_GraphQL

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

GraphQL

概要

  • 簡単ではない（≒苦行）らしい。

  • API（≒ WebAPI）のために作られた、

    • データクエリとデータ操作のための言語
    • 保存されたデータに対してクエリを実行するランタイム

経緯

  • 2012 年に Facebook の内部で開発され、2015 年に公開。
  • 2018 年 11 月 7 日、Linux Foundation がホストする
    新たに設立された GraphQL Foundation に移譲された。

特徴

  • REST やその他の Web サービスと比較して、

    • 効率的
    • 堅牢
    • フレキシブル

    なアプローチを提供。

  • クエリ言語の特徴

    • 柔軟性と豊かな表現が可能
    • 反面、複雑さを加え、シンプルな API には適さない可能性。

補足: GraphQL が効くのは、 クライアントごとに必要なフィールドが違うケースである。 REST では

  • 必要以上のフィールドが返る（over-fetching）
  • 1 画面を作るのに複数回叩く必要がある（under-fetching / N+1 リクエスト）

の両方が起きるが、GraphQL は 1 リクエストで必要な形だけを取れる。 逆に、クライアントが 1 つしかない業務システムでは、 得られる利点よりサーバ側の実装コストのほうが大きくなりやすい。

詳細

構成

  • 型システム
  • クエリ言語
  • 実行セマンティクス
  • 静的な検証
  • 型イントロスペクション

機能

機能概要

  • クライアントが必要なデータの構造を定義することができ、

  • サーバーからは定義したのと同じ構造のデータが返される。

    • 必要以上に大きなデータが返されるのを防ぐことができる。
    • クエリ結果のウェブキャッシュの効果に影響を与える。

  • 基本的には、

    • NoSQL が対象だが、RDBMS も対象にできる。
    • GraphQL が直接的に DB とやりとりするわけではない。
    • まず対象となるデータをすべて、前もってデータベースから取り出しておく。
    • ここから、フィルタなどの処理を行い、必要なデータだけを取り出す。

移行メモ（補足）: 「まず対象となるデータをすべて前もって取り出す」は 素朴に実装した場合の挙動であって、推奨される作りではない。 実際には resolver ごとに DB アクセスが発生するため、 そのままでは典型的な N+1 問題になる。

対策として、

  • DataLoader パターン（同一リクエスト内の問い合わせをまとめて発行）
  • クエリの射影を DB のクエリまで伝播させる （HotChocolate の [UseProjection] など）

を用いる。これが「苦行」と言われる部分の実体である。

キャッシュの扱い

補足: GraphQL は原則 単一エンドポイントへの POST であるため、 キャッシュ・コントロールのHTTPヘッダ による HTTP キャッシュや CDN がそのままでは効かない。 REST が「URL 単位でキャッシュできる」という利点を 捨てている点は、採用判断で見落とされやすい。 対策は永続化クエリ（persisted queries）＋ GET 化、 あるいはクライアント側の正規化キャッシュ（Apollo Client 等）となる。

クエリと操作

  • 読み込み（Query）

    • Schema クラスを定義する。
    • Query クラスに以下を実装。
      • arguments — arguments を生成する。
      • resolve — arguments を使って resolve する。

  • 書き込み（Mutation）

  • データのサブスクリプション（Subscription）

移行メモ（正誤）: 元 Wiki では Subscription を 「WebHook で実装」としていたが、 GraphQL の Subscription はサーバからクライアントへの継続的なプッシュであり、 一般的な実装は WebSocket （graphql-transport-ws プロトコル）または SSE である。 WebHook（サーバ間のコールバック）とは別物である。

セキュリティ上の注意

補足: GraphQL 固有の注意点として、次がある。

  • クエリの深さ・複雑度をクライアントが決められるため、 深くネストしたクエリで容易にサーバを重くできる （depth limit / complexity limit を必ず設定する）。
  • イントロスペクションにより、 スキーマ全体が既定で外部から取得できる（本番では無効化を検討する）。
  • 認可はエンドポイント単位ではなく フィールド単位で考える必要がある。

サポート

クライアント

  • Apollo
  • Relay

※ JS クライアント。サーバも同梱。

サーバ

  • Apollo、Relay 以外は、
    個別のライブラリとして提供されているらしい。

  • 以下は、サポートがある言語。

    • JavaScript、Perl、Python、Ruby、PHP
    • Java、C#、Go
    • Scala、Haskell、R、Clojure
    • Elixir、Erlang

補足（最新化）: .NET では HotChocolate（ChilliCream）が 事実上の標準である。graphql-dotnet も現役だが、 新規採用は HotChocolate が多い。 Azure には Azure API Management の GraphQL サポートや Data API Builder という選択肢もある。

参考

Tags: .NET開発, 通信技術, .NET Standard, .NET Core, ASP.NET, ASP.NET Web API

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally