「マッチングプラットフォームを支えるフロントエンドからバックエンドまでのモダン開発について 」に参加した
海外におけるgraphql-rubyのチュートリアルや活用事例の紹介は，GitHub，Shopifyが利用していることもあり，徐々に増えつつある．
また，先日はカンファレンスが開催されるなどオフラインでコミュニティも活発である．
しかし，日本においては，まだまだ情報が表に出ていないため，対面で質問できる良い機会だと思い，参加した．
イベントでは，下記のようにデザイン管理，バックエンド，フロントエンド，CI/CDと多岐に渡った内容がLTで紹介された．
本記事は，関心の高かった「複数サービスを運用するコンポーネント設計」と「新規プロダクトのバックエンドで全面的にGraphQLを利用してみて」についてまとめる．
後日，connpassにて資料が公開されるようだ．
複数サービスを運用するコンポーネント設計
LTでは，スペースマーケットが抱えていた二つの課題にどう向き合ったかが紹介された． その課題とは，以下の２つだ．
コンポーネントの更新が手間
コンポーネント粒度にばらつきが出る
コンポーネントの更新が手間
スペースマーケットでは，一つのサービスに対して一つのリポジトリを割り当てている．よって，似たコンポーネントが複数のリポジトリに分散しているためデザインの一貫性と取ろうとすると，全てのリポジトリのコンポーネントを修正する必要があるためコストや抜け漏れが発生するという課題があった．
そこで，コンポーネントを管理するサービス共通コンポーネントというリポジトリにまとめることで，上記の問題点を改善した．
コンポーネント粒度にばらつきが出る
コンポーネント粒度は，悩ましい問題だ．スペースマーケットでは，Atomic Designを取り入れることで，改善を試みた．ここまでだと，どこの企業でもそれなりにやって珍しくない．スペースマーケットでは，Atomic Designで辛くなってくるコンポーネントの運用方法まで考えていた．
なぜ，コンポーネントの運用を考える必要があるのだろうか？近年のアジャイル開発での高速なPDCAサイクルは，デザインの変更頻度が高いことを示唆しており，開発が進むについて増加するコンポーネントを管理できなくなる問題が生じると考える．開発者においては，全てのコンポーネントを把握することは困難であるため，意図せず既に存在しているにも関わらず，似たようなコンポーネントを新規開発してしまう恐れがある．
スペースマーケットは，その問題を解決するためにコンポーネント運用の共有会やユーザーストーリーで利用するコンポーネントを可視化することで，知らないコンポーネントをなくす工夫を行った．
新規プロダクトのバックエンドで全面的にGraphQLを利用してみて
普段の業務でバックエンドエンジニアとしてGraphQLを利用していることから，かなり関心の高いテーマであった．事前にQueryの認証をどのように行うかを質問しようと思っていたが，物の見事に知りたい内容が全て紹介されていた良いLTだった．
ページネーション
GraphQLは，デフォルトでカーソルベースのページネーションが実装されている．graphql-rubyにおいても同様の実装だ．
カーソルベースのページネーションは，Twitterなどのページネーションを必要としない連続データに対しては，効果を発揮するが，ページネーションを利用するサービスには不向きであるという点がある．
そこで，スペースマーケットはページネーション機能として一般的なGemであるkaminariを利用してOffset&Limitページネーションを実装した．
graph-rubyは，version1.8よりDSLでのスキーマ定義からClass形式が推奨されるようになり1，そのままコピペすることは辞めた方がいいが，以下にその実装が紹介されている．
N+1問題
GraphQLでは，簡単にN+1問題が発生してしまう．
lazy_resolve というメソッドで一つ一つのオブジェクトに対して，遅延処理を行うことが可能だが，管理コストが高くなってしまう．
そこで，公式ドキュメントのLazy Executionを読むと，３つの対処方法が提案されている．
Gems for batching
The example above is simple and has some shortcomings. Consider the following gems for a robust solution to batched resolution:
graphql-batch provides a powerful, flexible toolkit for lazy resolution with GraphQL.
dataloader is more general promise-based utility for batching queries within the same thread.
batch-loader works with any Ruby code including GraphQL, no extra dependencies or primitives.
LTでは，graphql-batchとdataloaderの簡単な紹介が行われた．graph-batchを利用しているとのことだ．懇親会にて，batch-loaderを選定しなかった理由を聞くと，開発が盛んでないということであった．確認してみると，確かにcommit，Star，Fork数が少ない．
graphql-batchは，公式で利用企業として紹介されているShopifyが開発していることもあり，信頼できる．新しい技術やGemが提案されるまでは，graphql-batchを利用して良いと感じた．
GraphQLサーバーへのデータの受け渡し
GraphQLサーバーへのデータの受け渡しのフォーマット標準は，JSONだ．
よって画像のアップロードが困難なので，Base64でエンコードして送ってやる必要があるようだ．しかし，データサイズが33%程増加するため，解決策を模索しているようだ．
アクセス権限管理
graphql-rubyは，Authentication(認証)を標準でサポートしている．
Mutationに対しては，ほぼ全てに対して認証をつけるので抽象化やコントローラにて一括で認証を行うことができる．
Queryでは，意図しない他ユーザー情報とグラフで繋がってしまうという問題があるが一々認証を書くとは面倒だ．
スペースマーケットでは，graphql-guardというGemを利用してFieldに対して認証をかけているようだ．
まとめ
- RailsアプリケーションにおけるGraphQLの活用事例を聞いた
- コンポーネント設計後の運用が大事
- Queryの認証は，graphql-guardが便利
- 懇親会で技術のことを話すのは，楽しい
あとがき
GraphQLのコミュニティが発足したようなので，のぞいてみるとよいかも．
GraphQLについて相談できるSlackチャンネルを作りました。
— Yoshinori Kosaka (@wawoon_jp) 2019年7月5日
・GraphQLをすでに使っている人
・興味がある人
・導入するか検討したい
など、関心があるかたたちが情報交換 / 相談できる場所にしたいと思っています。https://t.co/fVNaNvYzoG
