最高のGraphQLクライアントを求めて Apollo vs Relay

GraphQLの代表的なクライアントと言えば、ApolloとRelayの2つです。 どちらも素晴らしいソフトウェアですが、この2つは根本的に異なる背景で作られています。

今回は、みなさんがそれぞれ最高のクライアントを選ぶことができるようにお手伝いしたいと思います。

なお、本来Relayと比較するのはApolloのOSSの中でもApollo Clientとなりますが、ここではApolloと記載しています。RelayもRelay ClassicではなくRelay Modernの方です。 URQLについては今日は触れません。

---

2022年6月追記: 続編記事を書きました。

---

企業的な背景

ApolloとRelayは2つともGraphQLクライアントではありますが、背景に存在する2つの企業の目的は完全に異なります。

Apollo

Apolloは元々Meteorの開発元が作成したGraphQLを扱うためのソフトウェア群です。Apolloの急成長により、創業者はMeteorを売却してApolloに集中するようになりました。

Apolloのビジネスモデルは、Apollo Clientを中心にしたOSSを使用している企業に対して、いくつかのサポートを有料提供することです。例えばコンサルティング、可視化のシステム、Datadogなどの他システムとの連携などを有料提供しています。 つまり、この企業はApollo Clientを使用するユーザーが増えれば増えるほど儲かります。

そのためApolloの最優先事項は、RESTを使用しているユーザーにGraphQLを使わせることです。現状、GraphQLを使っているユーザーよりRESTを使っているユーザの方が多いので、そのユーザーのシームレスな移行を狙っています。

このためにApolloは血の滲む作業を継続しています。

まず、Apolloは多様な環境で動作します。仮にバックエンドをGraphQLにしたところで、WebアプリやモバイルアプリがAPIに接続できなければ意味がありません。 このため、Apollo ClientはWeb/iOS/Androidのクロスプラットフォームで使うことができます。 バックエンド用のライブラリを含む多くのOSSも提供しており、GraphQL界隈で使用される様々なものがApolloとそのコミュニティの努力によって支えられています。¹

また、ユーザーが簡単に使い始められるように常に努力しています。GraphQLに入門するだけで若干大変なので、クライアントを使う時にセットアップや覚えるものがなるべく少なくなるように配慮されています。 Apolloは入門コストを下げることにかなり意識的です。後述しますが、Relayより明らかに始めやすいです。

ドキュメントを手厚くしたり、カンファレンスを開いたり、コミュニティの意見に耳を傾ける努力もしています。 もちろん、これらは超多様な範囲をカバーする必要があるため完璧とはいきませんが、確実に努力は行われています。

Relay

対してRelayはFacebookが開発しています。 FacebookはRelayを使って利益を回収しませんが、わざわざ人件費をかけて専門のコアチームを構成しています。 この理由はReactと同じです。つまり、facebook.comのような超大規模なコードベースを素早く安全に開発するためには既存の手法では難しく、より良いソフトウェアを求めているのです。 バグなく新しい機能を高速にFacebookのプロダクト群に投入すること、それがFacebookに利益をもたらします。

そのためRelayの最優先事項は、壊れないフロントエンドを最速で作ることです。GraphQLは常にその手段です。 彼らは自分達が使用している環境以外には興味が薄いため、念頭に置かれている環境はReactとReactNativeだけです。逆にReactとの連携を限界まで高めることに非常に熱心です。 また、サーバーサイドの仕様についてもGraphQLのベストプラクティス（という名のRelayのルール）に準拠していることを求めますし、フロントエンドの開発中に独自のコンパイラを使う必要もあります。 しかし、こうしたセットアップの面倒さを乗り越えたら、以降は爆速で壊れないフロントエンド開発に邁進できます。ここまでの多種多様な”仮定”により、システム側が使用できる知識が増えているため、人間が手動で設定したり気をつけるべき点が減ります。 かなりの部分を型安全で短く書け、かつ高いパフォーマンスを出すことができます。

比較表

Apollo（Apollo Client）とRelayを簡単にまとめてみます。

項目	Apollo Client	Relay
ユーザー数	◎	△
入門しやすさ	◎	△
公式の対象環境	React, ReactNative	React, ReactNative, iOS, Androidなど
スキーマ	高い柔軟性	ベストプラクティス準拠
堅牢性	○	◎
キャッシュ	○	◎
パフォーマンス	○	◎
ドキュメント	○	△
関連OSS	◎	△

ユーザー数はApolloの方が多いです。コミュニティとしてもApolloの方が繁栄していると思います。 最近ReactのSuspenseなどとの絡みでRelayユーザーも増えつつあるようですが、絶対数ではまだまだApolloの方が上です。

入門のしやすさはそもそもGraphQLの導入で覚えることが多いですが、Apolloの方がしやすいです。Relayは学習曲線がかなり急で、正しく動くまで混乱しがちです。

公式の対象環境は圧倒的にApolloが優れています。将来的にRelayで公式に他の環境が充実していく可能性もあるかもしれませんが、今のところそのような兆候はありません。

スキーマはApolloの方が柔軟ですが、柔軟であるが故にコンピューターに与えられる知識が少なかったり、チームで統一されなかったりと、どちらが良いかは意見が分かれます。

堅牢性はRelayの方が優れています。コンパイラがかなりの部分をチェックできる上に、コンポーネントの密結合（データの依存）を強制的になくすなど、Relayの方が堅牢性を重視しています。また、多くを自動化するために（手動で書かないので）ミスが減ります。

キャッシュは、機能はApolloの方が、安全性はRelayの方が優れています。 Apolloは手動でキャッシュを弄る部分が多くハマりがちですが、Relayはほとんど自動化されていて安全に使えます。一方Apolloは手動で弄るために色々な機能が用意されており、それを使ってキャッシュデータに対してハック（例えば文字列を加工するとか）ができます。多機能ですが、こうした手動ハックは基本的に必要ない（むしろ怪しい挙動をもたらす）と個人的には思うのでApolloの点数を下げました。

パフォーマンスはRelayの方が優れています。Relayではデータの変更時にクエリに関連する全てのコンポーネントを更新するのではなく、データに変更があったコンポーネントだけを自動的に更新します。Apolloも同様のことができますが手動です。

ドキュメントはApolloの方が優れています。Apolloのドキュメントも完全とは言い難いですが、Relayよりはかなり良いと思います。

関連OSSはApolloの方が優れています。前提として、通常必要なものはどちらにもあります。Relayはオールインワンで、Apolloは組み合わせて使います。 ただ、単純にユーザー数が違うのでエコシステムの繁栄度は異なりますし、Apolloの方が関連OSSは多いです。Apolloが小さく小分けしてくれてるので、むしろRelayユーザーも足りないものはApolloのOSSに全力で乗っかってます。

まとめ

過去、Relayではsubscriptionやローカルステートの管理などができませんでしたが、現在は問題なくできますので、重要な機能的な違いはほとんどないと思います。

イメージとしてはTypeScript使うときにstrictを絶対つけたい人はRelayと相性が良いと思いますし、自由度を求めるならApolloを使う方が良いのではないでしょうか。 Apolloは自由の国、ちょっと手動、RESTより安全だけどまだデンジャラスな部分は残ります。 Relayは規律ガチガチの国、ほぼ自動、デンジャラスな部分は抹殺！という世界観です。

私はRelayを多く使っていますが、今回は可能な限りフェアに書いてあるつもりです。Apolloに配慮するあまり、逆にApolloの採点が甘口になっている疑惑はありますが…（比較表に△ないですし）。 もしこれを読んでRelayも学んでみようかなと思う方がいれば嬉しく思います。ディープに学んでみたい方はこちらの記事を見てみてください。

おまけ

最後にRelay信者としてフェアな比較から離れ、Relay最高！と言っている記事としてQuoraでの事例を紹介します。

QuoraのGraphQLクライアントの選択

かなり充実した良い記事だと思いますが、Relay信者寄りなのは否めない。