Slide 1

Slide 1 text

GraphQLを導入して よかったこと 大変だったこと

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

所属:株式会社iCARE 名前:安田俊之 関わってきた技術 Ruby => Ruby On Rails JavaScript => Vue.js, AngularJS PHP => Symfony, FuelPHP, CakePHP Java => Androidアプリ、Spring Perl => CGI DB => PostgreSQL, MySQL, Oracle, PL/SQL 3

Slide 4

Slide 4 text

本題 4

Slide 5

Slide 5 text

概要 1. Carelyでは、GraphQLをどんな風に使っているか? 2. GraphQLを使ってどんな点が良かったか? 3. GraphQLを使ってどんな点が大変だったか? 5

Slide 6

Slide 6 text

その前に、GraphQLってなに? 6 SQL SELECT fullname, email FROM customers GraphQL query { customers { fullname email } } GraphQLとある通り、SQLのような問い合わせ言語(query langage)

Slide 7

Slide 7 text

その前に、GraphQLってなに? 7 とはいえSQLに変わるものなどではありません。 SQLはDBへの問い合わせ言語であるのに対して、 GraphQLはGraphQLサーバーへの問合せ言語です。 GraphQLからDBに問い合わせる場合は、 GraphQLクエリ => GraphQLサーバー => SQL => DB という経路をたどることになります。 レイヤーが増えることで、複雑さは増しますが、柔軟性を獲得できます

Slide 8

Slide 8 text

CarelyでGraphQLをどんな風に使っているか? 8 GraphQL導入までのCarelyの歴史的経緯 1. Railsオンリー構成 ...シンプルなフロントエンド 2. REST構成 … ちょっとリッチなフロントエンド 3. GraphQL構成 … もっとリッチな(リッチー・ブラックモア) ※「なぜGraphQLを導入したか?」については、「GraphQLを使ってどんな点が 良かったか?」と重なるので説明を省略します

Slide 9

Slide 9 text

Railsオンリー構成 9

Slide 10

Slide 10 text

REST構成 10

Slide 11

Slide 11 text

現在の構成(GraphQLを利用) 11

Slide 12

Slide 12 text

RESTとGraphQLの実装の比較 12 弊社におけるREST時の実装とGraphQL時の実装を無理やりパラレルに並べ て比較してみました

Slide 13

Slide 13 text

実装の比較(リクエスト) 13 REST https://some.where/customers GET GraphQL https://some.where/graphql POST query { customers { fullname email } }

Slide 14

Slide 14 text

実装の比較(インターフェース) 14 REST app/controllers/customers_controll er.rb class CustomersController def index @customers = Customer.some_scope end end GraphQL app/graphql/types/query_type.rb module Types class QueryType < Types::BaseObject field :customers, [CustomerType], null: true def customers @customers = Customer.some_scope end end end

Slide 15

Slide 15 text

実装の比較(詳細定義) 15 REST app/views/customers/index.json.jb uilder json.customers @customers do | c | json.name c.name json.email c.email ... end ↑ 該当のリクエスト専用の定義のため再利用不 可 GraphQL app/graphql/types/customer_type.r b module Types class CustomerType < Types::BaseObject field :name, String field :email, String end end ↑ 該当のリクエスト専用の定義ではないので再 利用可能(ActiveRecordの定義同様)

Slide 16

Slide 16 text

実装の比較(型定義の再利用) 16 query { orders { price datetime customer { name email } } } 上記のように異なる構造のクエリの場合でも、 jbuilderの定義と異なりCustomerTypeの定義 はそのまま再利用できる( Jbuilderでもpartialを 使って頑張れば再利用できるが、上記のように 属性を選択的に返却することはできない )

Slide 17

Slide 17 text

実装の比較(レスポンス) 17 REST { "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ] } GraphQL { "data":{ "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ] } }

Slide 18

Slide 18 text

実装の比較(入れ子構造へのリクエスト) 18 REST customerに紐づくorders(注文)を取得するとき は、customerごとに別途リクエストをする必要 がある GraphQL GraphQL側の型定義さえあれば、1回のクエリ で入れ子構造のデータを取得することができる query { customers { fullname email orders { price datetime } } } ※N+1問題に気をつける必要がある

Slide 19

Slide 19 text

GraphQLを使ってどんな点が良かったか? 19 1. エンドポイントが一つ(/graphql)になるので、Webサーバーにエンドポイントを どう作るかについて悩む必要がなくなる 2. データ定義を資産として再利用できる(RESTの場合のjbuilderだと再利用で きない) 3. リクエスト側から入れ子構造でデータを問い合わせることができるため、1回 のリクエストで複雑な構造のデータを柔軟に取得することができる。(ので、 サーバー側に、たくさんエンドポイントを用意する必要がなくなる) 4. バージョン管理について考えなくて良い(クライアント側で問い合わせ内容に 変更を加えれば良い) 5. GraphiQL(ブラウザインターフェース)でスキーマ(どんなフィールドがある か)の確認および動作確認ができる

Slide 20

Slide 20 text

GraphQLを使ってどんな点が大変だったか? 20 1. GraphQL + Vue.js + Railsの情報がネット上に意外と少ない 2. レイヤーが一つ増えることで開発およびトラブルシューティングの難易度が やや上がる 3. GraphQLの開発時に、GraphQL固有の仕様を習得せねばならず、そこそこ の習得コストがかかる(急ぎの開発がある時に、GraphQL開発がぶつかると よけいなオーバーヘッドになり、開発者に負担になる) 4. フロントエンド側でほしいデータを明示的に記載しなければならないので、初 期開発時にサーバーサイドとフロントエンドの両側で定義をしなければなら ない(restの場合、フロントエンド側はurlをたたくだけなので、フロントエンド側 の作業が楽)

Slide 21

Slide 21 text

さいごに 21 デメリットもあるけど、どう考えてもRESTよりいいよね! (まあ、後発だから当たり前って言えば当たり前かもしれないけど)