Skip to content

Instantly share code, notes, and snippets.

@svjunic

svjunic/graphql-study-1.md

Last active October 25, 2019 04:27
Show Gist options
  • Save svjunic/bb856d8fd70e092cea62b603d2797103 to your computer and use it in GitHub Desktop.
Save svjunic/bb856d8fd70e092cea62b603d2797103 to your computer and use it in GitHub Desktop.
Download ZIP
graphqlのおべんきょ
Raw
graphql-study-1.md

GraphQL

GraphQLは、2012年にFacebookによって社内で開発された後、2015年に公開されました。 GraphQLプロジェクトは、2018年11月7日にFacebookから非営利のLinux Foundationがホストする新しく設立されたGraphQL Foundationに移行しました。 GithubのAPIがGraphQLに移行したことが有名。

概要

サーバサイドで動くプログラム（以降、GraphQLサーバ） GraphQLはAPI用のクエリ言語です。 やり取りの方法は、以下三種類で使い分けます。（間違ってたらごめん）

  • データの取得をQuery
  • 書き込みをMutation
  • サーバと情報をリアルタイムで共有するSubscription（WebSocket）

※Subscriptionはapolloのほうでやる

経緯

RESTfulでは、エンドポイントが多く、かつ表示する際に複数のAPIを叩かなければならない問題があり、 その問題を解決するための手段として作られたのがGraphQL （たぶんあってる）

対応言語

  • C# / .NET
  • Clojure
  • Elixir
  • Erlang
  • Go
  • Groovy
  • Java
  • JavaScript
  • PHP
  • Python
  • Scala
  • Ruby

対応言語を見てもらえると分かるが、とても多くの言語に対応している さわってみたところ、サーバ側の処理と表示用の処理で切り分ける設計がしやすくなることが特徴に思える

特徴

エコシステム

  • 1リクエストで複数のことがこなせるようなエコシステムを作ることができる
  • リクエストを減らすことで、サーバ負荷を減らす

たとえば、ログインしなければ見れないサイトがあったとして ログインAPI、ログイン後の画面用のAPIがあることは容易に想像ができて、ひどい場合はログイン後のAPIは３つ４つ組み合わせるようなことが起きる これがREST APIの問題点。 冷静に考えると、１つ１つリクエストが完了したら、という処理は本末転倒な状態であり、ログインしたらログイン後に表示するデータが帰ってくる設計のほうが良い。

勘違いしないでほしいところ

RESTful APIと競合するものではない
RESTful APIは設計通りに作ることで整理はされているが、逆に設計通りにすると何度もAPIを叩く必要が出てくる。
RESTfulだとAPIを呼び出すごとにセッションなりアクセストークンなりを使ってログイン認証を確認しているが、そういう部分をGraphQLを使って一本化することでフロントもサーバも楽になる、そういう仕組み。

RESTfulAPIが有用なことももちろんあり、必ずGraphQLを使わなきゃいけないという仕組みではない。 もし、コストが許すなら両方公開しても誰も損はしない、そういう仕組。

個人的なBADパターン

GraphQLに処理を書いてしまうこと

GraphQLを活かせる状況

DB面

変な認証処理は減るかもね？ぐらいかと。 ↓webの意見 リレーショナルデータベースで、中間テーブルが腐るほど作られるような複雑なシステムの場合 うーん、あんまり実感がない。 GraphQL側に色々書くと処理が分散するので、正しいとは言いづらい感じ。 NoSQLのように自由に設計ができてしまう場合、Schemeが生きる Schemaに型が宣言されるため、何のデータかわかりやすい。 （違う方が帰ってきたらそもそもエラーになる） データをくっつけて返す、ということも可能だからそういう点では利点がありなのか・・・・？ GraphQL側で処理をたくさん書くのは、そもそも設計ミスのような気がする。

サーバでのメリット・デメリット

メリット

  • SchemaがAPIの設計書の役割を担うことができるため、フロントとサーバサイドでのコミュニケーションが取りやすい
  • デバッグが容易
  • RESTfulAPIがすでにあっても、資産として流用が可能 デメリット
  • 工数・教育コストはかかる

フロントでのメリット・デメリット

メリット

  • 非同期処理の簡潔化が可能
  • 画面遷移が減らせる場合もでてくる デメリット
  • 工数・教育コストはかかる

サーバレスでのメリット・デメリット

メリット

  • 他のAPIからデータを取得して整形、レスポンスまでの処理がわかりやすい デメリット
  • 工数・教育コストはかかるが、大きなデメリットはないかと

GraphQLが向かない状況

めちゃくちゃ重いデータを受け取る場合、一本化することで更にレスポンスのデータが重くなるのでhttp2には向かない場面もあるかもしれない

ここまでの感想

メリットはわかる。 ドキュメントが英語が多く、かつ対応する言語が多いのでめっちゃ調べづらい。 ベストプラクティスがわかりづらい

  • ディレクトリ構成
  • クエリの作成

Appendix

https://tech.mercari.com/entry/2018/11/30/100332

nodejsのgraphql

graphql https://graphql.org/graphql-js/ 単体で使う人はおらんとおもうが、かいてある。 express-graphql https://graphql.org/graphql-js/running-an-express-graphql-server/ express組み込み用に提供されている

https://graphql.org/graphql-js/basic-types/

お勉強用リポジトリ

https://github.com/svjunic/sandbox-express-graphql.git

mutationとかは書き込みのqueryになるので、今回はAPIもないので割愛

この時点での感想

  • mongooseのschemeとgraphqlのschemeの書き方が違うので、設計が変わるごとに更新がだるい
  • ドキュメントはあるんだけど、graphql-jsについての説明はすくない
  • node.jsだとexpress-graphqlがすでにあるので、組み込みやすい
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment