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

Transcript

1. GraphQLを導入して よかったこと 大変だったこと
2. 自己紹介 2
3. 所属：株式会社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
4. 本題 4
5. 概要 1. Carelyでは、GraphQLをどんな風に使っているか？ 2. GraphQLを使ってどんな点が良かったか？ 3. GraphQLを使ってどんな点が大変だったか？ 5
6. その前に、GraphQLってなに？ 6 SQL SELECT fullname, email FROM customers GraphQL query { customers { fullname email } } GraphQLとある通り、SQLのような問い合わせ言語（query langage）
7. その前に、GraphQLってなに？ 7 とはいえSQLに変わるものなどではありません。 SQLはDBへの問い合わせ言語であるのに対して、 GraphQLはGraphQLサーバーへの問合せ言語です。 GraphQLからDBに問い合わせる場合は、 GraphQLクエリ => GraphQLサーバー => SQL => DB という経路をたどることになります。 レイヤーが増えることで、複雑さは増しますが、柔軟性を獲得できます
8. CarelyでGraphQLをどんな風に使っているか？ 8 GraphQL導入までのCarelyの歴史的経緯 1. Railsオンリー構成 ...シンプルなフロントエンド 2. REST構成 … ちょっとリッチなフロントエンド 3. GraphQL構成 … もっとリッチな（リッチー・ブラックモア） ※「なぜGraphQLを導入したか？」については、「GraphQLを使ってどんな点が 良かったか？」と重なるので説明を省略します
9. Railsオンリー構成 9
10. REST構成 10
11. 現在の構成（GraphQLを利用） 11
12. RESTとGraphQLの実装の比較 12 弊社におけるREST時の実装とGraphQL時の実装を無理やりパラレルに並べ て比較してみました
13. 実装の比較（リクエスト） 13 REST https://some.where/customers GET GraphQL https://some.where/graphql POST query { customers { fullname email } }
14. 実装の比較（インターフェース） 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
15. 実装の比較（詳細定義） 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の定義同様）
16. 実装の比較（型定義の再利用） 16 query { orders { price datetime customer { name email } } } 上記のように異なる構造のクエリの場合でも、 jbuilderの定義と異なりCustomerTypeの定義 はそのまま再利用できる( Jbuilderでもpartialを 使って頑張れば再利用できるが、上記のように 属性を選択的に返却することはできない )
17. 実装の比較（レスポンス） 17 REST { "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ] } GraphQL { "data":{ "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ] } }
18. 実装の比較（入れ子構造へのリクエスト） 18 REST customerに紐づくorders（注文）を取得するとき は、customerごとに別途リクエストをする必要 がある GraphQL GraphQL側の型定義さえあれば、１回のクエリ で入れ子構造のデータを取得することができる query { customers { fullname email orders { price datetime } } } ※N+1問題に気をつける必要がある
19. GraphQLを使ってどんな点が良かったか？ 19 1. エンドポイントが一つ(/graphql)になるので、Webサーバーにエンドポイントを どう作るかについて悩む必要がなくなる 2. データ定義を資産として再利用できる（RESTの場合のjbuilderだと再利用で きない） 3. リクエスト側から入れ子構造でデータを問い合わせることができるため、1回 のリクエストで複雑な構造のデータを柔軟に取得することができる。（ので、 サーバー側に、たくさんエンドポイントを用意する必要がなくなる） 4. バージョン管理について考えなくて良い（クライアント側で問い合わせ内容に 変更を加えれば良い） 5. GraphiQL（ブラウザインターフェース）でスキーマ（どんなフィールドがある か）の確認および動作確認ができる
20. GraphQLを使ってどんな点が大変だったか？ 20 1. GraphQL + Vue.js + Railsの情報がネット上に意外と少ない 2. レイヤーが一つ増えることで開発およびトラブルシューティングの難易度が やや上がる 3. GraphQLの開発時に、GraphQL固有の仕様を習得せねばならず、そこそこ の習得コストがかかる（急ぎの開発がある時に、GraphQL開発がぶつかると よけいなオーバーヘッドになり、開発者に負担になる） 4. フロントエンド側でほしいデータを明示的に記載しなければならないので、初 期開発時にサーバーサイドとフロントエンドの両側で定義をしなければなら ない（restの場合、フロントエンド側はurlをたたくだけなので、フロントエンド側 の作業が楽）
21. さいごに 21 デメリットもあるけど、どう考えてもRESTよりいいよね！ （まあ、後発だから当たり前って言えば当たり前かもしれないけど）