GraphQL を Ruby から触る

by mmyoji

4 min read

ruby graphql

GraphQL をクライアントから触る場合にどういうクエリ書いたらいいか、くらいのことをドッとなったときに見たが GraphQL Server 側の話はノータッチだったのでちょこっと勉強した。

How to GraphQL というサイトに上がっている動画を一通り見て概要を把握して、 Ruby の tutorial を少しだけやった程度

GraphQL とは?

GraphQL is a query language for APIs - not databases.

クエリ言語であって DB ではないよ、とのこと。

また「あくまでただの specification (仕様) でしかない」ので、具体的な実装は色々あるから適当に選んで使うなり、自分で実装するなりしてねとのこと。

Schema Definition Language

独自の Schema Definition Language (SDL) で諸々定義していく。

Person type や Post type などと言ったエンティティの定義や、データ取得、書き込み・更新(mutation)、購読(subscription) といったクエリの定義

ここらへんは上に挙げたサイトを見れば大体わかる。

subscription の実装は各実装に依存すると思うが実際に必要になったときに勉強しようと思う。

余談だが、 graphql-ruby を使った tutorial では定義も Ruby で書いてしまっていて、 Ruby エンジニア以外には抵抗感が出るんじゃないかなと感じた。

定義の中に実装も含んで書かれているので仕方ないような気もするが、うーんという感じ。ただ、 development 環境では /graphiql にアクセスすることでクエリの実行環境を活用できるのでそこで schema 定義を見たり、クエリを試せるので十分な気もする

Architecture

  1. GraphQL server with connected database
  2. GraphQL server that is a thin layer in front of a number of third party or legacy systems and integrates them through a single GraphQL API
  3. A hybrid approach of a connected database and third party or legacy systems that can all be accessed through the same GraphQL API

一応雑に訳すと、

  1. DB と繋いだ GraphQL server
  2. 既存のシステムと繋いだ GraphQL server
  3. 1 + 2

という感じで GraphQL server が実際にどういうデータソースからデータを取ってくるかは実装次第でかなり自由にできる。

ruby の tutorial では

クライアント <-> GraphQL Server <-> SQLite

という感じでシンプルだったが、 GraphQL Server からは特定の API を叩いたりしても（理論上は）問題ない

ただデータソースへのリクエストは graphql-ruby + graphiql-rails を使う限りにおいては自分でちゃんと実装してないと最適化されないのでそこらへんは backend 屋さんの腕の見せ所だと思う（適当）

正直そこそこめんどくさいと思う

Ruby にこだわらないのであれば今の所 Apollo を使うのが無難そう

Caching

あと cache について少し気になったので調べた。

主に CDN caching に関して。

エンドポイントが基本的に POST /graphql (path はなんでもいいが）になり、 request body を見れないので request が多いものをどうやって cache すればいいのか。

結論としては GraphQL vs REST: Caching を見てもらえばわかるように（自分が誤解していなければ） Etag を利用することで解決できるとのこと

また、一般的に POST /graphql が使われるだけであって、別に GET request を使っても問題ないとのことなので、 request 多い箇所に関してはそうしてもいいのでは？みたいな意見も見かけた。

ただこれに関しては GraphQL が REST より優れている点として挙げられている「単一エンドポイントへの request でほしいデータがすべて取れる」という利点を失うことになりかねないため、個人的にはイケてない解決策だと思っている

まとめ

もういろんな人に言及されているが、 GraphQL を導入することの最大のメリットは client と backend の developer が余計なコミュニケーションを取る必要がなくなることだと思う。

Schema さえ見ておけばそれでお互いがお互いの実装に集中できる。また version 管理も不要になりそうなので、それも backend 的には嬉しい点になりそう

場合によっては layer が一個増えると捉えることになると思うが、 legacy system と graphql server をメンテする人は大抵同じ人か近いレイヤーを普段から扱っている人な気がするので、そんなに問題はなさそう。

問題があるとすれば GraphQL Server の実装が大変そうという点だが、これは慣れの問題でもありそうだし、良い実装が出てきたら解決されると思うので、今やらないといけない人はがんばりましょう

かなり粗があるがこんな感じで今日のお勉強は終わり