Help us understand the problem. What is going on with this article?

GraphQL勉強会発表資料(補足)

More than 1 year has passed since last update.

2017.6.7(水)に社内で開催したGraphQL勉強会の発表資料の補足ページです。

発表資料
GraphQL勉強会 2017.6.7 // Speaker Deck

FAQ

Q1. GraphQLってなんなの?

A1. GraphQLはクライアントからサーバーへの問い合わせに使用するクエリー言語(仕様)です

  • プログラミング言語ではなく、クエリー言語
    • アプリケーションレイヤー
    • 一種のDSL
  • クライアント/サーバーアプリケーションのデータモデルの機能と要件を説明するためのもの
  • 2012年にFacebookによって作成され、2015年までFacebook社内で使用されていた
  • GraphQLが提供するもの
    • 統一言語、タイプシステム、API仕様取得機能

Q2. GraphQL を使うと何が嬉しいの?

A2. メリットは以下の通りです

  1. クライアントアプリケーションが必要とするデータを1回のリクエストで取得できるようになる
    1. モバイルネットワークで特に有効
    2. 複数のデータソースを1回のリクエストでまとめて取得できる
  2. APIのエンドポイント1つだけ、1つのエンドポイントで様々なリクエストに対応できる
    1. さまざまなクライアントに1つのエンドポイントで対応でき、プラットフォーム、クライアントアプリケーションのプラットフォームやバージョンの影響を受けない
  3. クライアントアプリケーションからサーバーにリクエストを投げる際に、統一されたインターフェースが提供されているので、クライアント/サーバーそれぞれの実装に影響を受けずに開発を進めることができる
  4. タイプシステム(型)とセルフドキュメンテーション
    1. タイプシステムのお陰でクエリのバリデーションが容易になる
    2. 型定義自身がドキュメントとなるため、別途ドキュメントを用意する必要がなく、またドキュメントとAPIの仕様が異なるという現象を防ぐことができる
  5. GraphQLの開発をサポートするツールの恩恵を受けられる
    1. GraphiQL が優秀

Q3. 逆に GraphQL のデメリットは?

A3. デメリットは以下の通りです

  1. サーバーサイドの実装が大変
    1. RFCに従って一からサーバープログラムを自作するのは容易ではない
    2. プロジェクトで使用する場合は、すでに幾つかサードパーティ製の実装があるので、それを使用するのがよい
  2. クライアント側で、何のデータが必要なのかを「すべて」明示する必要がある
    1. 1回のリクエストでのコード量は増加する
    2. とはいえ、アプリケーションがどのデータを使用しているか明示されるため、後で見た時にわかりやすく拡張し易い
  3. 文献が少ない
    1. 英語のドキュメントがほぼ(2017.6.7現在)
  4. パフォーマンス最適化のベストプラクティスがない
    1. リクエストの形が毎回変わる可能性があるのでキャッシュが(REST APIに比べて)難しい

Q4. GraphQLを実際に使ってみたい!

A4. 手っ取り早くを試すなら以下のサービスがよいです!

Q5. ユーザー認証はどうやるの?

A5. 基本GraphQLは認証には関与しないので、別に考える必要があります

  • GraphQLの中で認証することも、既存のAPI認証の仕組みをそのまま使用することもできる
  • 参考: https://idobata.io/ja/api

Q6. GraphQL実装はどのようなものがありますか?

A6. 以下のページにリストアップされています

Q7. GraphQLを理解するポイントは?

A7. 以下がポイントになります。

  1. REST APIと違いすべてのリクエストはPOSTになる
    1. 例外的に、型情報を取得するもののみGET
    2. それ以外はすべてPOST
  2. 「クエリー(Query)」と「ミューテーション(Mutation)」の2種類がある
    1. クエリーは副作用を伴わないリクエスト
    2. REST APIのGET相当
    3. ミューテーションは副作用を伴うリクエスト
    4. REST APIのPOST/PUT/PATCH/DELETE等
  3. CQRS( Command Query Responsibility Segregation コマンドクエリー責務分離)
    • データの読み込みと書き込みは別のものとして考える
  4. GraphQLのレスポンススピードはqueryの中で解決が一番遅いものに引っ張られる
    • 早く取得したいものと遅いものをそれぞれ別のクエリで取得すると良い

参考文献

notakaos
東京在住のWeb Developer
yumemi
みんなが知ってるあのサービス、実はゆめみが作ってます。スマホアプリ/Webサービスの企画・UX/UI設計、開発運用。Swift, Kotlin, PHP, Vue.js, React.js, Node.js, AWS等エンジニア・クリエイターの会社です。東京(三軒茶屋)/京都(四条烏丸)/札幌/大阪/福岡に展開中!Twitterで情報配信中https://twitter.com/yumemiinc
http://www.yumemi.co.jp
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした