謝辞

タイトルは大袈裟に言いました。7度くらい変わります。

誰のためのどんな記事か

この記事は、GraphQLを聞いたことがある、興味を持っているといった方からGraphQLを使ったけど良さが全然わからんという方向けです。
また、この記事をとおして

  • 自分にGraphQLは必要か
  • RailsでGraphQLを始める上でおすすめの構成

がわかると思います。GraphQLとは？みたいな話は調べればいくらでも出てくるので特に話すつもりはありません。

また、ここで話すGraphQLはRelayというスタイル(ページネーションについての規約)で説明を進めていきます。

GraphQL、APIの認識

よくRESTにするか、GraphQLにするかという文脈で語られるのでRESTとGraphQLがまるで別物かのような認識を持たれる方がいらっしゃいます。
まず初めに正しい認識から入れていきたいのですが、イメージとしてはRESTという土台があってGraphQLに昇華するような感じです。
そもそもWeb APIは、世界のどこかにあるデータに対してXXが欲しいだの、YYYYみたいなものを作ってくれだの消してくれだのといった要求を送り付け、結果を受けとるための仕組みで、RESTはURLで「あるデータ」、つまりリソースを指定してHTTPメソッドで要求の種類(作って欲しい、渡して欲しい、更新して欲しい、削除して欲しい等)を指定し、必要があればBodyという要求を送る際の補足情報にJSON形式などでデータを添えます。
GraphQLのMutation/Query + Inputも同様にリソースに対して取得・変更要求を出します。
わかりやすいように、それぞれを比較していきます。

想定ケース

ニュースのデータが10件欲しい

リソースの指定

REST

  • Request
    url: GET https://example.com/api/v1/news&p=1
    body: null
  • Response 
    {
"news": [
{
  "id": 1,
  "title": "Title",
  "content": "This is News"
},
...,
{
  "id": 10,
  "title": "Title",
  "content": "This is News"
}
],
"total_num": 234523
}

GraphQL

  • Request
    url POST https://example.com/api/graphql
    body: 
    query GetNews {
news(first: 10) {
    edges {
        node {
            id
            title
            content
        }
    }
}
}
  • Response 
    {
"news": {
"total_count": 434523,
"edges": [
  {
    "node": {
      "id": 1,
      "title": "Title",
      "content": "This is News"
    }
  },
  ...,
  {
    "node": {
      "id": 10,
      "title": "Title",
      "content": "This is News"
    }
  }
]
}
}

見比べてもわかるように、URL部でやっていることをBody部でやっているだけです。

GraphQLのメリットとどういう人が使うといいのか

先程の例を拡張して現場あるあるな事例を混ぜていきましょう。
ニュースリーダーサイトを作っていたとして、ニュース一覧ページで先程のAPIは使われるでしょう。
また、その現場ではフロントをReactで、サーバーをRailsで別々の人が実装しているとします。
最初はニュース一覧ページではタイトルを表示するだけでしたが、ある日デザイナーがそこに著者情報を入れたいといってきました。

もちろんすでにモデル側の設計としてNewsに著者情報が保持されていることが前提となりますが、RESTだとバックエンドとフロントエンド双方で追加開発が必要となり、GraphQLを採用していればフロントのみの変更ですみます。

こういう話は日常茶飯事でフロントの都合に合わせてサーバー側のコードを書き換えが増えたり、無茶なテーブルの関連付けが行われたりします。

「ここのページこうしたいからレスポンスをこういうふうにして」という要求に耳を傾ける必要性を下げられると、サーバーはデータやドメインオブジェクトがどうあるべきかという設計に注力できるのでハイパフォーマンスなシステムを構築しやすくなります。

また、Railsを長く使っている人はわかると思いますが、サービスクラスやFormオブジェクトといった標準的にはRailsに存在しないレイヤーを追加して綺麗にリクエストに対する処理を実装しているが、そうなるとなんのためのRailsなんだ。。。という疑念にかられる時があります。
標準化された、リクエストに対して特化したオブジェクトを手に入れる方法としてもGraphQLには非常に大きな魅力があります。

なのでGraphQLが向いている人というのは

  • フロントの仕様変更の多い現場
  • サーバーサイドでフレームワークの標準仕様にないリクエスト処理機構を取り入れている人

になるかと個人的には思います。

RailsでGraphQL APIを作る際のおすすめ

会社でボイラープレートを作りました。
こちらにおいておくので興味のある方はご覧ください。

  • ページネーションにはRelayスタイルを使った方がいい
  • 上流で例外集めていい感じにGraphqlErrorに
  • 認証はContextの状態で管理
  • テストは統合テストはせずにQuery, Mutationともに型ごとのテストを実装

筆者自身、CoadmapというサービスをReact + Railsで、GraphQLを採用して作りました。
このボイラープレートに実装してあることも実際にその時に書いたコードから切り出して作っています。

私のメンタリングでは初心者の方の学習サポートからサービス設計はもちろん、中級者の開発スキルの向上や、転職に向けて現場向けな知識までサポートさせていただきます。

興味のある方はメッセージをお願いします。