色んな事を書く

シンプルさを極めたエンジニアになりたい

GraphQL 入門 1

会社のプロジェクトで GraphQL を触ることになりました。良い機会なので、GraphQL に入門しようと思います。

GraphQL とは

GraphQL を一言でまとめると「柔軟な Web API のためのクエリ言語と、そのクエリのための実行環境」です。Web API の仕様のようなものです。

クライアントが必要としているデータを独自に定義する事が可能で、その定義通りのデータがサーバからレスポンスされます。

特徴としては

  • 一回のリクエストで複数のリソースを取得出来る
  • クライアント毎に必要なデータの定義が出来る
  • スキーマファーストで API を設計出来る

といったことが挙げられます。

実現したい事は API 設計の柔軟性を高め、開発者が扱いやすいようにすることだと思います。なぜそれが実現出来るのか具体的に見ていこうと思います。

GraphQL が生まれた背景

そもそもなぜ GraphQL が誕生したのかその経緯を追い、解決したかった課題についてみていきます。もともと GraphQL は Meta(旧 Facebook)によって開発されました。GraphQL が誕生する以前は REST ful API で開発を行っていたようなのですが、処理の複雑化やパフォーマンス低下などを引き起こす要因となってしまっていたようです。

Meta に限らず、REST ful API を使っていると以下のようなシチュエーションに出くわしたことがあるのではないでしょうか。

  • ある画面を表示するのに複数の endpoint を叩く必要がある
  • あるデータが欲しいが、レスポンスに含まれる全ての field が必要なわけではない
  • アプリケーションの要件が変わると新しい endpoint の追加や既存 endpoint の修正作業が発生する
  • 複雑化したクエリパラメータ

などです。これらの状況が課題に繋がってしまうかもしれません。

例えば、複数の endpoint を叩く場合にはネットワークリソースを消費してしまいます。不必要な field を持ってしまうとメモリを消費してしまいます。新しい endpoint を追加すると管理コストは増えますし、既存を修正するには影響範囲の調査など発生するかもしれません。こういったことが課題として顕在化する事もあると思います。

ちなみに、クライアントにとって不要なデータを取ってくることをオーバーフェッチングと言います。場合によってはパフォーマンスの低下につながることもあると思います。逆に、必要なデータを取ってこれない事をアンダーフェッチングと言います。

GraphQL のメリット

なぜ GraphQL が誕生したのかはわかりました。ここからは GraphQL を採用するメリットについてまとめます。クライアント・サーバサイド双方から見ていきます。

クライアント

  • 必要なデータを指定出来るので、オーバーフェッチングやアンダーフェッチングを防ぐことが出来る
  • 必要なデータを指定出来るので、一度の Request で必要なデータのやり取りが完結する
  • API 仕様を一元化出来る
    • C# API、Rust API があっても、クライアントから見れば GraphQL に集約されている
  • スキーマファーストであり、Request・Response は型安全である

サーバサイド

  • クライアントの都合に引っ張られて API を修正する必要が減る
  • データソース (データの提供元) を切り替えるのが簡単で状況に応じて変更しやすい
    • C# の REST full API から Rust の gRPC API に変更、など
  • スキーマベースの API になるので、ドキュメンテーション作業はコミュニケーションコストが減る

柔軟性があるとうたっていますが、一番の強みはクライアントが求めているデータの構造を定義出来るというだと思います。あるユースケースにおいて必要な情報、不要な情報はあって、クライアント側でスキーマを定義すればそれらを取捨選択が出来ると。それが結果的にオーバーフェッチングやアンダーフェッチングを防ぐ事に繋がっていくのだろうと。

REST ful に設計された API ってどうしても一つのエンドポイントで一つのリソースを返すようになります。それってどうしてもテーブルの構造に引っ張られたり、サーバサイドの都合によって開発されることってあるんじゃないだろうかと。それが結果的に複雑化していくクライアントの柔軟性を奪って課題が顕在化してきたんでしょう。

終わりに

自社開発企業に勤めているとプロダクトはリリースして終わりではなく、そこからが本番です。ユーザの要件や世の中の流れは常に変化します。そういう変化に素早く対応し、ユーザのニーズを満たし続ける事が事業にとって重要なことと思います。

プロダクトではなく、Web API という小さな単位で見てもそういう変化に強いものが求められるのだと思います。リリースして終わりではなく、運用や保守が求められます。開発者の生産性を落とさず、楽にプロダクトを成長させるために GraphQL のような柔軟な Web API があるのだと思います。あるアーキテクチャを採用した時に、プロダクトの保守性がどうなっていくのかを想像するのは今後も続けていこうと思います。ただ GraphQL が誕生してからずいぶん経ちます。GrapQL ならではの課題もあるでしょうし、それはまた別の機会に学ぼうと思います。

参考記事

graphql.org

zenn.dev