Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

yasudatoshiyuki

October 16, 2019
Tweet

More Decks by yasudatoshiyuki

Other Decks in Programming

Transcript

  1. 所属:株式会社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
  2. その前に、GraphQLってなに? 6 SQL SELECT fullname, email FROM customers GraphQL query

    { customers { fullname email } } GraphQLとある通り、SQLのような問い合わせ言語(query langage)
  3. CarelyでGraphQLをどんな風に使っているか? 8 GraphQL導入までのCarelyの歴史的経緯 1. Railsオンリー構成 ...シンプルなフロントエンド 2. REST構成 … ちょっとリッチなフロントエンド

    3. GraphQL構成 … もっとリッチな(リッチー・ブラックモア) ※「なぜGraphQLを導入したか?」については、「GraphQLを使ってどんな点が 良かったか?」と重なるので説明を省略します
  4. 実装の比較(インターフェース) 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
  5. 実装の比較(詳細定義) 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の定義同様)
  6. 実装の比較(型定義の再利用) 16 query { orders { price datetime customer {

    name email } } } 上記のように異なる構造のクエリの場合でも、 jbuilderの定義と異なりCustomerTypeの定義 はそのまま再利用できる( Jbuilderでもpartialを 使って頑張れば再利用できるが、上記のように 属性を選択的に返却することはできない )
  7. 実装の比較(レスポンス) 17 REST { "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ]

    } GraphQL { "data":{ "customers":[ { "fullname":"山田太郎", "email":"taro@yamada", } ] } }
  8. GraphQLを使ってどんな点が良かったか? 19 1. エンドポイントが一つ(/graphql)になるので、Webサーバーにエンドポイントを どう作るかについて悩む必要がなくなる 2. データ定義を資産として再利用できる(RESTの場合のjbuilderだと再利用で きない) 3. リクエスト側から入れ子構造でデータを問い合わせることができるため、1回

    のリクエストで複雑な構造のデータを柔軟に取得することができる。(ので、 サーバー側に、たくさんエンドポイントを用意する必要がなくなる) 4. バージョン管理について考えなくて良い(クライアント側で問い合わせ内容に 変更を加えれば良い) 5. GraphiQL(ブラウザインターフェース)でスキーマ(どんなフィールドがある か)の確認および動作確認ができる
  9. GraphQLを使ってどんな点が大変だったか? 20 1. GraphQL + Vue.js + Railsの情報がネット上に意外と少ない 2. レイヤーが一つ増えることで開発およびトラブルシューティングの難易度が

    やや上がる 3. GraphQLの開発時に、GraphQL固有の仕様を習得せねばならず、そこそこ の習得コストがかかる(急ぎの開発がある時に、GraphQL開発がぶつかると よけいなオーバーヘッドになり、開発者に負担になる) 4. フロントエンド側でほしいデータを明示的に記載しなければならないので、初 期開発時にサーバーサイドとフロントエンドの両側で定義をしなければなら ない(restの場合、フロントエンド側はurlをたたくだけなので、フロントエンド側 の作業が楽)