nakamoriのblog

Apollo Clientにいろいろ足しながらRelayと比較する

Thu, 09 Jun 2022 07:06:10 GMT

以前にApollo ClientとRelayの比較記事を書きました。当時はApollo Clientを使い込んでいませんでしたが、1年以上Apollo Clientを使ってきたので適切な比較ができる頃合いだと思います。

今回はApollo ClientとRelayとの比較ではありますが、Apollo Clientにいろいろなツールを足しつつ比較してみたいと思います。 Apollo Clientはそのまま使うことはおそらく稀なので、こうした比較をすることでより良い比較ができる + 自作のOSSのNauをちょっと紹介する😎ということが目的です。

Apollo ClientとRelayのどちらのツールも使用したことがない方には少し難しい内容になっている可能性があります。容赦ください。

私の状況

比較の前に私がどの程度Apollo ClientとRelayを理解しているかについて書きます。

まずRelayですが、使用歴1年半ほどです。Relayの設計方針の翻訳記事をこのブログに置いています。本番で使用していました。 Apollo Clientについても使用歴1年以上、本番で使用しています。Apollo Client用のツールであるNauを1年以上作っています。

`Apollo Client` vs `Relay` の概況

ざっくりとした話として、Apollo Client or Relayの技術選択について、簡単に触れていきたいと思います。

まず周りに配慮せず使用技術を決められるならRelayがおすすめです。 Relayの方が効率的で効果的で保守性が高い形でプログラムを書くことができます（というよりそのような形でしか書けません）。ただし、チームメイトが使いこなせなかったり、Relayの想定する使い方と違うやり方をすると、途端に大変になります。ある程度自分で責任取れる人向けです。

一方Apollo Clientはプログラムを書いて動かすまでの敷居がとても低いです。また柔軟性・拡張性が高いのも特徴ですね。ただし、保守性の高いプログラムを書こうとするとGraphQL Code Generatorなどの別プロダクトを併用しないといけなかったり、キャッシュの仕組みを詳細に理解しなければなりません。

※ 今回は触れませんが、どちらを使用する場合でもバックエンドのGraphQL APIはRelayのGraphQL Server Specificationに準拠しておいた方が後々幸せになれます。Apollo Clientを使う場合でも準拠したバックエンドを構築したほうが良いです。

Apollo Clientにいろいろ足しながらRelayと比較する

ここからはApollo Clientに様々なツールを足していきながらRelayと比較していきたいと思います。実際Apollo Clientを使う時にそれだけで使用するということはほぼないので、「何を使ったらApollo ClientはRelayと同じぐらいの保守性や利便性が手に入れられるのか？」という観点で比較していきましょう。

`Apollo Clientだけ` vs `Relay`

最初にそのままのApollo ClientとRelayとの比較について考えます。

残念ながらそのままApollo Clientを使うだけでは、TypeScriptの型も生成できませんし、書いたQueryが正しいのかも分かりません。すぐ壊れるので正直厳しい世界です。 Apollo Clientは簡単に始められるという利点はありますが、RelayとApolloの両方で本番運用をした経験がある人なら（この状況では）間違いなくRelayを推奨すると思います。それほどApollo Clientだけで書いたプログラムは脆弱です。

`Apollo Client + GraphQL Code Generator` vs `Relay`

Apollo ClientにGraphQL Code Generatorを併用することで、かなりまともな環境が手に入れられます。

GraphQL Code GeneratorはRelayのコンパイラと似たようなことをしてくれて、TypeScriptの型を出力したりQueryの静的解析をしてくれます。若干GraphQL Code Generatorのプラグインに精通しておかないと何をどう使えばよいのか分からないこともありますが、1日かけてドキュメントを読み込めばなんとかなる範囲なので頑張りましょう。

この状況でApollo ClientがRelayに劣っている主な点は次のとおりです（Reactの最新機能への追随などは除きます。GraphQLクライアントとしての観点のみで考えます）。

保守性：

フラグメントに閉じた変数などが使えないため、コロケーション（コンポーネントとフラグメントを近い場所に置いて運用すること）がうまくいかないです。コロケーションせずにスケーラブルなアプリケーションを作るのは中々難しいところがあります。
キャッシュのバグは本当に解明しにくいのに、ちょっとリッチな機能を作ろうとするとキャッシュを直接弄る必要があるのでバグりやすいです。ページネーションやSubscriptionを使う時はキャッシュを弄りがちで、バグりがちです。

効率：

Queryをリフェッチする時にフラグメント単位でリフェッチできないため、たびたびページのQuery全体を再実行する必要がありバックエンドから見て効率が悪いです。
仕組み上、Queryからデータを得ると全てのコンポーネントが再レンダリングされるためパフォーマンスチューニングが難しいです。

`Apollo Client + GraphQL Code Generator + Nau` vs `Relay`

Apollo Client陣営にNauを参加させてみます。

NauはRelayにインスパイアされたApollo Client用のツール（GraphQL Code Generatorと一緒に使います）で、コロケーションを行うための各種ディレクティブや、フラグメント単位でのRefetch機能、バグりやすいキャッシュ制御のためのツールなどを提供しています。 Nauを使う場合はバックエンドがRelay GraphQL Server Specificationに準拠している必要があります。

NauはRelayの機能をGraphQL Code Generatorの上でApollo Client流に再現しているものと言えます。 Nauを使うことで先に述べたほとんどの課題は解決されます。残ったのは「Queryからデータを得ると全てのコンポーネントが再レンダリングされるためパフォーマンスチューニングが難しい」だけです。これもNauに入れたいところではありますが、まだ実装できていません。

まとめ

いろいろなツールをApollo Clientと一緒に使用することである程度Relayの機能をカバーできること、そしてそれらを標準搭載しているRelayのオールインワン感がお分かりいただけたと思います。

ちなみに、これを書いている私は、お客様のところで技術選定をする場合はRelayでのリスクを引き受けられないのでApollo Clientを最初に提案します 😇 自分でやる場合はRelay一択なのですが…。人間だもの。

Apollo Clientの強みと弱みを考える

Sun, 05 Jun 2022 08:02:09 GMT

突然ですが、Apollo Clientの開発を支援するツールである Nau を作り始めて1年以上が経過しました。

この間、さすがにApollo Clientについて多少は詳しくなりました。せっかくなのでこの1年の開発から得られた学びなどを、今後いくつかに分けて話していけたらなと思います。今回はNauの開発を始めるキッカケになったApollo Clientの強みと弱み、特に生産性や開発者体験に目を向けて話していきましょう。

なお、ここではApollo Clientに加えてReactとTypeScriptの使用を前提として話します。その他の環境についてはあまり詳しくないので、私の考えが妥当でない可能性があります。ご注意ください。

Apollo Clientの良いところ

Reactで使うGraphQLクライアントと言えば、Apollo Client・Relay・urqlあたりが有名です。私はもともとRelayを使っていましたが、2020年末頃からお手伝いしているお客様の案件でApollo Clientを使い始めました。

Apollo Clientを始めてまず感じた良さは、開発者に対して手厚い支援があるところでした。ドキュメントやサンプルは豊富にありますし、Apollo Studioなどのクエリの実行環境からVS Codeのエクステンションやブラウザのエクステンションまで、一通りあります。対して、当時のRelayは（現在は改善されていますが）ドキュメントがほぼなくソースコードを見て細かい挙動を解析するような生活を強いられていたので、それと比較すると体験は当然良かったです。

また、Apollo Clientは柔軟で高い拡張性があり、実行時に行われるほぼ全てに干渉できます。それによりサードーパーティー文化が盛り上がっているかはさておき、困った時に自分で簡単な処理を書いてハックできるところは技術選定では安心感がありますね。

最後に、単純に使用している人が多いので、調べたらGitHubのIssue含め答えが出てきやすいところも技術選定観点では安心です。

Apollo Clientの良くないところ

良くないところは、ハッキリ言ってRelayと比較すると大規模なアプリケーションではバグりやすいことですね。悲しいですがそう言わざるをえません。 Apollo Clientのバグが多いという意味ではなく、Apollo Clientで作ったアプリケーションにバグを仕込んでしまう可能性が高いです。

まず、そのまま使うとQueryからTypeScriptの型を生成できませんし、書いたQueryが正しいのか実行前に静的に検証できません。普段TypeScriptを使っているユーザーからするとJavaScript時代に戻ったのかのような感覚になります。なので、ほとんどのユーザーはGraphQL Code Generatorと一緒に使って、TypeScriptの型やコードを自動生成したりQueryの検証をしたりしています。

ここまではGraphQL Code Generatorがあるので良いでしょう。本当の辛いところはここからです。

キャッシュ関連は酷いです。バグの温床です。「下手に弄るとすぐバグるから、とりあえずキャッシュ使わずにリフェッチして正しい状態にしよう」みたいなのはあるあるなバッドノウハウだと思います。 Apollo ClientはRelayと異なりバックエンドのスキーマがどうなっているか事前に定めないので、フレームワーク側でキャッシュ関連の自動化が困難です。できることと言えば、様々なケースに対応した柔軟性の高いキャッシュの仕組みを提供するということになりますが、その柔軟性、もとい複雑性が人類が使いこなすにはまだ早すぎるように感じます。

また、Relayでは常識となっているコロケーションが困難なのも大規模なアプリケーションでは辛いところです。ここで言うコロケーションというのは、フラグメントとコンポーネントを同じところに配置し、コンポーネントとコンポーネントで必要なデータの定義をセット運用することです。こうすることで、コンポーネントに必要なデータがコンポーネントの外部に依存しないのでリファクタリングが容易になります。しかしながらApollo Clientでコロケーションしようとすると、フラグメント内に閉じる変数を作れなかったり、フラグメント単位でリフェッチできなかったりするので、なかなか上手くいきません。

総じて、アプリケーションが大きくなるにつれてRelayは（慣れもあり）開発者体験が良くなっていくのに対して、Apollo Clientでは全く逆のことが起きると感じます。始めるのは簡単ですが大きくするのが難しいです。

対応策

そんなこんなでApollo Clientの開発者体験は若干厳しいのですが、当然ながら様々な努力が過去に、または現在進行形で存在しています。

日本語で参照できる情報としては、QuramyさんがApollo Clientでコロケーションが行える仕組み作りにチャレンジされています。 https://qiita.com/Quramy/items/b4d42f5b1c52d5cc171d https://github.com/Quramy/apollo-link-fragment-argument

GraphQL Code Generatorでコロケーションを行えるようにするプラグインも存在しています。これは内部的にRelayのコンパイラを使用しています。 https://www.the-guild.dev/blog/graphql-codegen-relay-compiler https://www.graphql-code-generator.com/plugins/relay-operation-optimizer

異色なところでは、用途は違うのですがApollo Client上にRelayのAPIを完全に作ってしまうものなんかもあります。当然コロケーション等ができます。こちらも内部的にはRelayのコンパイラを使っていたと思います。 https://github.com/microsoft/graphitation

そして私は Nau というツールを作っています。 https://github.com/kazekyo/nau Relayへの依存なしで、コロケーションをサポートしたり、ディレクティブ等でキャッシュの処理を宣言的かつ簡易に書くことができるようなツールです。

Apollo Clientの弱みと向き合う

Apollo Clientの根本的な弱みは「静的解析が苦手」「前提条件が少なく自動化できる領域が狭い」「一緒に使用するツールを限定できないため連携を極められない」みたいなところにあります。これらの弱みはApollo Clientが簡単さや間口の広さを重視しているからと言えるので、今後劇的に改善されるような未来はあまり見えません。 Apollo Clientはその代わりに拡張性を高めているので、なんとかGraphQL Code Generatorのようなサードパーティーのツールでうまく補完しながら付き合っていきたいですね。みなさんも、業務で作った仕組みがあれば是非OSS化していただけると良いと思います。人類が幸せになれる余地はまだたくさんあるのではないでしょうか。

ちなみに、私が作っているツールの目標はこれらの弱みを踏まえて、「Relayのサーバー仕様に準拠しているバックエンドがある」環境に限定して「Apollo Clientのやり方に沿った形で開発者の体験を向上させる」としています。 Apollo Clientユーザー全員は救えませんが、利用環境をある程度限定した状態で、その中で体験を良くするということですね。

またNauの紹介は後日書きたいと思いますので、今日はこの辺りで。

Relay Meetup #2 レポート

Fri, 05 Feb 2021 03:35:31 GMT

今回は2021年12月3日開催のRelay Meetup #2のレポートをお届けします。ここ最近は忙しくて記事が書けていませんが、遅れてもRelay Meetupの記事投稿は続けられたらと思っています。

今回は主催者のGabriel Nordeborn、1stDibsからLiliana Matosと Rob Richard、Entria TechからSibelius Seraphini、そしてFacebookのRelayコアチームからJoseph Savonaが登壇してくれました。

Relay Meetupについて

Relay Meetupは、GraphQLクライアントであるRelayのミートアップです。今回もYoutube上でのオンラインミートアップとして開催され、参加者はYoutube上のチャットやDiscordでの交流となりました。全て英語となりますが、当日の模様はYoutubeのアーカイブに残っていますので是非ご覧ください。

正直なところ、私は英語のヒアリングが下手なので字幕なしだと分からないところもありますね…。このレポートは雰囲気で書いています（笑）

それではイベントのレポートに入っていきましょう！

1. Relay関連のニュース

イベントの最初はRelayの関連ニュースの紹介からとなりました。

Relay 10.1.0リリース

Relay 10.1.0がリリースされました。本記事を書いている時点で10.1.3までリリースされています。

主なトピックで言うと、前回のMeetupでも話していたStore updater directiveの種類が増えました。具体的には@appendNodeやprependNode、deleteEdgeなどですね。 Mutationでデータに変更を加えても直接キャッシュを弄るコードを書かなくて良いので本当に便利です。

他にもcacheConfigの拡張サポートだったりReact17対応が入ったようです。

meros

multipart responseの読み込みをサポートしてくれるライブラリであるmerosの紹介もありました。 Relay界隈でよく活動しているMarais Rossouwが作ってます。

本イベントでも話される@deferや@streamはGraphQLサーバーがレスポンスをmultipartで返す仕様で、クライアントはそれを受け取って処理できないといけません。 merosはそのあたりの処理をやってくれるライブラリのようです。

ちなみに、@deferのmultipartなレスポンスを受けるプログラムについて、日本語で解説している方がいますので気になる方は読んでみると良いかもしれません。 ⇒ GraphQL の @defer, @stream ディレクティブを試してみる

Graphql Helix

Graphql HelixはGraphQLサーバーを構築するためのライブラリの紹介です。こちらも@defer/@streamの文脈での紹介となります。 Graphql HelixはExpressなどのNode.jsのWebフレームワークをGraphQL対応させるためのシンプルなユーティリティ関数集といったところです。シンプルでミニマルなところを特徴としています。このライブラリは@defer/@streamに対応済みなので、これを使って簡単に@defer/@streamを動かすことができるようです。

2. Relay Workshop

メインセッションの前半パートはRelay Workshopについて。 https://youtu.be/5E5KdSU7Exs?t=938 これを読んでいる方にRelayの初学者がいるかは分かりませんが、初学者の方にとってはSibeliusが作っているRelay WorkshopはRelayを学び始める良い手段になると思います。

Relayは学習曲線が急な上に公式ドキュメントが薄く、私も学び始めは「このAPIどうやって動かすんだろう？」と思うことがしばしばありました。そして分からないのでRelayのソースコードを読んで調べるという…。

そこでRelay Workshopです。 Relay Workshopでは豊富な実例と共にRelayを学ぶことができます。サンプルはHook対応で書かれているので、これからのRelayのアップデートで忘れ去られる知識を覚えてなくて良いのも素晴らしいです。

今回のイベントでは、Relay Workshopがどんなワークショップなのか、どうやって使うのかも含めて説明されていますので、気になる方は動画も見てみてください。

Sibeliusも話していましたが、Relay初学者が心折れるところは「なんでか分からないけどRelayコンパイラが動かない」という時なんですよね。初学者じゃなくなるとそのコンパイルがあるからこそ安全に素早く書ける実感が得られるのですが、そこまでが長い。そうした障害に対して、動作するサンプルコードを豊富に用意することで解決するアプローチは素敵だと思います。

3. @deferと@stream

メインセッションの後半パートは@defer/@streamについて。 https://youtu.be/5E5KdSU7Exs?t=2807 @deferと@streamの話を1stDibsのLiliana MatosとRob Richard、そしてRelayコアチームのJoseph Savonaも参加していました。 1stDibsの2人は@defer/@stremを2020年に一気に実現に近づけた中心人物で、多くの仕様や実装案を作っています。彼らから直接話を聞けるのはとても良い機会でした。

@defer/@stream自体の解説も当然ありましたが、ここで説明すると長くなってしまうので割愛させてください。私も以前に解説を書いてますが、他にも日本語で素晴らしい記事を書いている方がいらっしゃいますのでそちらを見てみると良いと思います。 ⇒ Incremental Data Delivery with GraphQL defer and stream ⇒ GraphQL の @defer, @stream ディレクティブを試してみる

さて、イベントに話を戻します。冒頭のニュースでmerosの話がありましたが、同様のクライアントサイドのライブラリであるfetch-multipart-graphqlをRobが作っているようです。 merosの方がよりコアで汎用的に使える印象ですが、@defer/@streamのためにRelayで使うならこちらの方がサッと実装できそうな気配がしました。

@defer/@streamをRelayのHookなどと使う実例も見せてくれて、Relayと合わせて使うのはめちゃくちゃ便利そうです。早くクエリ分割をする世界から開放されたい…。

今回はチャットから質問を受けて様々なトピックについても話していたのですが、それも面白かったですね。例えば、なぜクエリ分割ではダメなのか？フィールドに@deferディレクティブはつけられないのは何故か？などなど…。おそらく日本語の記事で知れることが8割以上だと思いますが、仕様を深く理解している人達の解説は面白かったです。英語が未熟で一部何言ってるか分からないところもありましたが…。主催者のGabrielにYoutubeアーカイブに字幕つけてくれと言ってはいるので、後日字幕ついてるかもしれません。

まとめ

Relay Meetup #2のレポートでした。今回もRelayユーザーにとってはためになる、または今後が楽しみになる会だったのではないでしょうか。

次回のRelay Meetup #3は2月10日19:00 GMT+2からです。内容はRelayコアチームによるQ&A！とても面白そうな内容で、今年のRelayの計画・スケジュールについても聞けそうです。今回のミートアップでもRelayコアチームのJosephが少し触れてましたが、experimentalの（少なくともいくつかは）2021年内のリリースを計画しているようです。 ReactのConcurrent Modeに依存してるところはReact待ちになると思いますが、Hooksのリリースなどは早めに見たいところですね。

それでは、次回もお楽しみに！

Relay Meetup #1 レポート

Tue, 10 Nov 2020 06:27:35 GMT

2020年になって、Relayが盛り上がってきましたね！少し遅くなりましたが、今回は2020年10月21日にオンラインで初開催されたRelayのグローバルミートアップのレポートをお届けします。

今回は主催者のGabriel Nordeborn、元Artsyで現MicrosoftのEloy Durán、FacebookのRelayコアチームのJan Kassensの3名が登壇してくれました。

オンラインでの開催

今回はYoutube上でのオンラインミートアップとして開催されました。参加者はYoutubeのチャットやDiscordでの交流となりました。開始時間が日本時間で深夜2時ぐらいだったので私もリアルタイムでは見てなかったのですが、当日の模様は動画で残ってるので今からでも見ることができます。

ちなみに全て英語です。Youtubeの自動翻訳はついてますが、厳しい場合はこのレポートを読みながらご覧ください。

1. Relayコミュニティからのニュース

それでは内容に入っていきましょう。最初はFacebook外のRelayのコミュニティのニュースから。

Relayは長らくFacebook所属のコアチームが作っており、コミュニティとは距離を置いていると思われてきましたし、実際そういった面も否めません。しかしFacebook外のコミュニティメンバーからのコミットは継続的にあり、特に最近はインパクトのあるPRが外部から出されてマージされています。 Relay Meetupでコミュニティの活動が紹介され、目に見える動きがあるのはとても嬉しいことですね。

今回は下記が紹介されました。

Rustで作成中のRelayの本家コンパイラで、基本的なTypeScript連携が含まれました https://github.com/facebook/relay/issues/3182
DefinitelyTypedにあるRelayの型にexperimentalの機能を含む多くのアップデートが行われました https://github.com/DefinitelyTyped/DefinitelyTyped/pull/48638
webpackを使用したエントリーポイントのOSS実装が進行しています https://github.com/relay-tools/typescript-relayjs-examples/issues/1
react-relay-offlineというオフラインでrelayを使用できるようにするためのパッケージで、render-as-you-fetchがサポートされました https://github.com/morrys/react-relay-offline/pull/57

1と2はTypeScriptとRelayがより親密になるという話で、3と4はReactのrender-as-you-fetchを（OSS版での）Relayで実現する話です。

1のTypeScript連携も素晴らしいですが、3のエントリーポイントは今後がかなり気になります。ここで詳細は解説しませんがrender-as-you-fetchではJSを1ファイルではなく分割して後で追加でダウンロードします。今後、コンポーネントとデータの遅延ダウンロードの実装方法についてOSSでのガイドが出てきそうです。 SPAでJSのサイズが大きい問題から逃れられる日も近いかもしれません。

2. ArtsyでのRelayについて

Relayを使っている方はArtsyという会社を知っているかもしれません。Relayコミュニティに対して貴重なブログやgithubリポジトリを公開しており（プロダクションで使用されているコードが公開されています）、コミュニティ内では一定の認知度があります。今回はArtsyでのRelayの経験をalloy（Eloy Durán）が語ってくれています。

alloyは現Microsoftのエンジニアで、以前はArtsyで数年働いていました。彼はReactNative、TypeScript、RelayでArtsyのモバイルのアプリケーションを構築することになります。なぜそれらを選んだのか、どういった過程になり、Webやモバイルのチームがどう反応してくれたのかについて話してくれました。また、Relayの素晴らしさと学習の難点、OSSの貢献についても議論されました。

3. Mutationでのキャッシュアップデートについて

最後のパネルディスカッションで、Mutationでのキャッシュアップデートの戦略について議論されました。少し話が入り組んでるので、このパートは分かりやすいように内容をまとめ直します。彼らが話している順番で記載していないのでご注意ください。

まず、Mutation使用時の原始的なクライアントキャッシュの更新方法は、updaterを使ってストアの中身を自分で命令的に書き換えていくことです。 https://relay.dev/docs/en/mutations#using-updater-and-optimisticupdater これはまずまず大変です。型もなく、自分であれこれ操作しなければなりません。 Relayを使い始めた人は最初にupdaterを試すと思うのですが、結構難しくてどこが間違って動かないのか分からないですよね。まぁ、プロダクションコードではほぼ後述する方法を使うことになるので最初はあまり気にする必要もないと思いますが…。

updaterよりも簡単な方法として、updater configsでの宣言的な更新があります。 https://relay.dev/docs/en/mutations#updater-configs ストアを直接弄るよりも圧倒的に簡単でバグも少なく更新できます。例えばキャッシュからデータを削除する時はNODE_DELETEを使いますが、使い方さえ分かれば圧倒的に簡単です。

そして、最近RelayにマージされたStore updater directivesはさらに簡単です。具体的には@deleteRecord、@appendEdge、@prependEdge、@appendNode、@prependNodeのディレクティブです。名前からなんとなく分かるかもしれませんが、例えば削除するオブジェクトのidに＠deleteRecordをつけるだけで、Mutation実行時にキャッシュから削除できます。

mutation CommentDeleteMutation(
  $input: CommentDeleteInput
) {
  commentDelete(input: $input) {
    deletedCommentId @deleteRecord
  }
}

@appendEdgeなどを使えばConnectionにEdgeを簡単に追加することも可能になります。

さて、updater configsやStore updater directivesは便利ですが、全てをこのように宣言的に記述することは難しいのが現実で、ストアを直接弄る低レベルなAPI（= updater）が必要なシーンもあります。特に、他のオブジェクトにも副作用が発生するようなケースは宣言的に記述するのが難しいです。例えばFacebookでは友達をブロックすると、友達リストの他にフィードなど異なるidをもつオブジェクトを消さなければなりません。こうした副作用で様々な処理をするケースでは上記のように宣言的なキャッシュの更新だけでは対処が難しいので注意が必要です。

ちなみに、Relayのexperimental版にはInvalidation APIというものがあり、Mutationの実行時にキャッシュの古いデータ（一般的にはMutationで更新したことで影響されたであろうデータ）をマークしてRelayに教えることができるようです。これを使うことで、次に古いデータを評価するタイミングでキャッシュを使用せずに再フェッチできるんだとか。すごい。 https://relay.dev/docs/en/experimental/a-guided-tour-of-relay#staleness-of-data

まとめ

Relay Meetupの記念すべき初回のレポートをお届けしました。かなりディープで参考になる話題が盛りだくさんだったのではないでしょうか。最近はRelayの記事をいくつか書いたり主催者のGabrielとはRelayの翻訳関係でやり取りしたりしていたので、今回のミートアップの開催はとても楽しみにしていました。 Relayはコミュニティでの繋がりって世界的にもほぼないので、ここからコミュニティの活動も広まっていくと良いですね。

次回のRelay Meetup #2は12月2日19:00 GMT+2からです。前半パートでは、初心者向けにRelayのワークショップを作っている方が、Relayの始め方について教えてくれます。後半パートでは@deferと@streamについて、GraphQLの仕様にこれらのディレクティブを追加したメンバーが直接教えてくれます。少し前に@deferと@streamについて日本語で書いたので、そちらを見ておくと英語が苦手でも理解できるかも…？（私が嘘書いてなければ）

それでは次回をお楽しみに！

インフラをコード化するPulumiを実運用している話

Mon, 02 Nov 2020 11:15:00 GMT

Webサービスのインフラは年々複雑化しており、コード化なしにインフラを構築するのはどんどん難しくなっています。最近はIaC（Infrastructure as Code）のPulumiを使ってインフラをコード化しているので、使用感を書いてみようかと思います。

むかし話

私がまだ新卒だった2011年〜2012年あたりでは、ChefとCapistranoを使ってAWSのEC2のサーバーの構築を自動化していたような気がします。私がメインでやっていたわけではないのですが、Capistranoあたりは少し触っていました。その後はAnsibleも少し扱ったことがありますが、このあたりまでの記憶はほぼないので省略します。

明確に記憶があるのはAWSのリソースをYAMLで宣言的に記述できるAWS CloudFormationです。 CloudFormationはEC2の中身をセットアップをするようなものではなく、AWS上のリソースを用意するためのものです。EC2のサーバーを立てる、RDSを立てる、WAFを立てる、といったAWS上でのリソース全体を構築します。

この時代は既にサーバーの中身の構築はDockerにトレンドが移行していました。CloudFormationでAWS上のリソースを用意して、サーバーの中はDockerのImageを動かすということをしていました。

YAMLでリソースを作るの大変すぎ問題

CloudFormationはYAMLで書きます。これがなかなか辛いです。当たり前ですがYAMLには型がないので、ドキュメント見ながら書いてても普通に間違えちゃうんですよね。タイポというより、オプション等のネストの指定の仕方などYAMLでの構成を間違えてしまいます。

悪いことにAWS側のYAMLの検証が微妙で、記述が間違ってても普通にデプロイが走ってしまうことがままあり…というか今は分かりませんが当時は間違っててもほぼ通ってしまい、実行時にミスが分かってロールバックされるのが辛いです。もっと酷いとロールバックできなくなって手動で戻さないといけない時もあります。

顕著に悪い部分が出るのは、DBやCloudFrontなど作るのに時間がかかるリソースの作成や更新の時ですね。デプロイ始めてから30分後にロールバックされてしまうと、1日8時間勤務だとして16回しか試せないという…。

また、プログラミング言語で書けば一瞬で終わるようなものを地道に書かなければならなかったり、YAML上で特殊な記法を使って保守性を高める必要があったりする点も微妙でした。

そしてPulumiへ

とにかくYAMLが嫌で、型のあるモダンなプログラミング言語でAWSを構築したいという思いでPulumiに飛び込んでいきました。今であればAWS CDKも良いと思うのですが、当時はまだ生まれたてだったので選択肢には入りませんでした。

PulumiはモダンなIaCです。簡単に特徴をまとめると、次の通りです。

TypeScript、Python、Go、.Net（C#など）といったプログラミング言語でインフラの構成を宣言的に記述できます
AWSやGCPなどマルチクラウドのリソースを構築できます
Kubernetesのマニュフェストなどもプログラミング言語で書けます

私はTypeScriptで書いていますが、とても生産性が高いです。

Pulumiを実運用した感想

しばらく運用しているので簡単に感想でも。

良いところ

TypeScriptで書けるのはとても便利です。型がある点だけでなく、インフラでのコンテキストスイッチが小さくて済む点もお気に入りですね。私はフロントもバックエンドもTypeScriptで書くので、いざインフラのコードを書く時も違和感なく書けます。

もう1つお気に入りなのは、PulumiではDevOpsで必要なワークフロー全体をシームレスに統合できるところです。例えば、k8sのサポートがかなり入ってるので、PulumiのコードとしてDockerのimageを作って、レジストリに上げて、k8sのマニュフェスト更新するところまでワンストップで短い行数で記述できます。あとはGithubのPull Requestのマージ時にそのコードをCI/CDでキックするだけで、自動的にk8sのPodを入れ替えることができます。他にも、アプリケーションやインフラで使用する各種シークレットの管理もできます。DBのパスワードをコード上で作ってから、k8sのPodの環境変数に埋め込んだりできるので、パスワード管理しなくて良い部分も多いです。

他にもインフラの構築を便利にするもの（例えばDBの移行スクリプト的なものを作れるAPIなど）がたくさんあり、痒いところに手が届きます。

微妙なところ

Pulumiはマルチクラウドに対応しており、AWSやGCPなど様々なところでリソースを作れます。AWSやGCP以外にも、変わったところでは認証基盤であるAuth0でテナントを立てたりできます。

これはProviderという、雑に言うとプラグインシステムのようなものを本体と一緒に使うことで実現されています。AWSのProviderやGCPのProviderがあり、それ経由でリソースを構築するということです。

そのPulumiのAWSのProviderなんですが、なんと競合のTerraformがOSSとして作っているterraform-provider-awsをベースに、型を導入するなど手を加えて使っているんですね。ドキュメントにもしっかりとThis Pulumi package is based on the aws Terraform Provider.と書かれています。

それ自体は良いのですが、terraform-provider-awsで対応が遅れているリソースは当然Pulumiにもないんですよね。例えばAWSにWAFv2のリソースが作れるようになってから半年以上は、Terraformが対応できてなかったのでPulumiも同時に対応していないという状況だったと思います。

また、terraform-provider-awsから生成した型が微妙なところがちらほら。インスタンスタイプなど、明らかに型をUnion（またはEnum）で表現できるところをstringにまとめちゃっていて、タイポできる余地が残っているところがあります。

まとめ

正直、Pulumiにはかなり満足しています。今までのインフラ構築の体験の中でベストな体験です。 AWSのリソースを作るということ以上に、アプリケーションとインフラの構築プロセスの全てがちゃんと便利になっている実感があります。

しかし不満がないわけではなく、不満の一部はAWS CDKに分があるように思うので、時間があればAWS CDKも見てみようかなと思っています。

リッチテキストエディタを作れるSlate、2020年の状況

Sun, 01 Nov 2020 06:00:22 GMT

Webサービスにリッチテキストエディタの機能をつける時、自分でフルスクラッチで書くのは大変です。 Draft.jsを筆頭にOSSで使えるものはいくつかあり、私はSlateを使っています。そんなSlateの現状について、使用者の一人としてざっとまとめていきたいと思います。

なお、2020年11月1日現在の話であり、あなたがこれを見ている時には状況が変わってる部分も多くあると思います。

私がSlateを使い始めた理由

2018年頃、当初はFacebook製のDraft.jsを利用していました。しかしながらDraft.jsを使って複雑なプラグインを書くのが大変だったのと、何よりDraft.jsで共同編集の実装に必要なノウハウをインターネット上で発見できなかったので、代わりを探し始めました。これはDraft.jsで共同編集の実装が不可能であるというわけではなく、当時の自分にガイドなく実装できるだけの知識がなかったというだけです。もしDraft.jsで共同編集を実装したい人はGithubのIssueを覗いてみると良いかもしれません。

さて、当時から（今も）SlateはBeta版です。プロダクションでの利用は推奨されていませんでしたが、共同編集へのサポートとプラグインの書きやすさ（内部状態の可読性とAPIの扱いやすさ）から移行を決定しました。 Slateへの移行で共同編集を含む様々なプラグインを実装でき、当時はSlateに満足していました。

現在のSlateの状況

しかしながら2020年末現在、Slateは少し雲行きの怪しい状況にあります。もちろん悪いニュースだけでなく良いニュースもあるのでそれも含めて紹介していきたいと思います。

作者不在

まず、作者であるIanは2020年になってほとんどSlateに参加していません。Slackはもちろん、GithubのIssueやPull Request（以下PR）にも出てきません。 READMEには作者から「改善が必要な場合は（報告するだけでなく）自分でコントリビュートしてください」というような、まぁ至極当然ではあるのですが、そういう記載が加えられました。

作者はもともと関与している時期とそうでない時期の差が大きかった気がしますが、今年は本当に全然参加していないので、Slateは数人のメンテナが保守的にPRをマージしています。しかしAPIの変更を伴うような”判断”が必要な議論はあまり進んでおらず、コミュニティ全体の活動が低下しています。バグフィックスのPRでさえ全ては処理できない状況です。

Slackでは「最悪、リポジトリをフォークして使うのが良いよ」というアドバイスが飛び交っております。来年は状況変わるんでしょうか。

日本語入力のサポートはまだ厳しい

以前より良くなっていますが、日本語入力のサポートはまだ厳しい状況が続いています。厳密に言えば日本語というよりもIMEを使っての入力がよくバグります。例えばSafariではIMEを使って入力すると、常にカーソルが行頭に飛ぶなどの致命的なバグがあります。

バグ自体は良いのですが、問題は修正PRが全くマージされないことです。このPRとかこのPRとか。 Slackでも何度も話題に上がってますが、アクティブなメンテナの中にIMEを使っている人がいないみたいなので致し方ないです。変えたければ自分がメンテナになれって話なので。何人かはリポジトリをフォークしてIME関連のパッチを当てて使ってるようです。

どうなるAndroidサポート

モバイル対応ですが、iOSはともかくAndroidは現時点で動きません。ちなみにネイティブの話ではなくモバイルのブラウザの話で、ネイティブはターゲット外です。

Androidで動かすためには複雑なハックが必要なようです。そのようなハックを作者Ianが前のバージョンアップ時に全部消しちゃったので、Androidは動かなくなりました。

そこで再度入れようという話になったのですが、Androidサポートは元々Ianではなく別のメンテナが担当していて、その人が金銭的な寄付を求めるという事態になり、コミュニティが若干ざわつきます。個人的には「お金を払えば作ってもらえるなら最高じゃん」と考えているので、このプロジェクトに寄付しました。

お金は無事集まって完成に向かって走っているようですが、今後どれぐらいメンテされるんでしょうか。

プラグインは超前進

プラグインに関してはとても良いニュースがありました。 SlateはAPIが秀逸でプラグインが作りやすいのですが、Slateに残ってるバグを踏むこともままあり、それなりに詳しくないと品質の高いプラグインは作れません。そんななか、今年活発に開発されているプラグイン集のslate-pluginsは質と量ともに大変素晴らしいです。

Slateで何ができるかはslate-pluginsのStorybookを見たら分かるといっても過言じゃないぐらいのプラグインの見本市です。コードも綺麗なのでちょっとソースコードを見れば自分でも拡張できます。私は自分で書いていたプラグインのほとんど（共同編集など以外）をslate-pluginsにリプレースしました。

slate-pluginsでは今のところGithubでIssueやPRを投げたら反応早いですし、Slackでのチャンネルも活発です。

私のこれから

slate-pluginsは素晴らしいものの、本体の開発状況を考えると雲行きは怪しいと言わざるをえません。申し訳ないですがメンテナになるほどの気力はなく、移行を考えています。

移行先として考えているのはProseMirrorですね。IMEがちゃんと動いてくれて、プラグインが満足に組めればそれで良いので、そこだけ祈ってます。共同編集については別で書きたいと思うのですが、自分で作らなくてもProseMirrorにはy-prosemirrorというCRDTで動くプラグインがあるので良さそうです。一応Slateにも似たようなものはありますが、今のところ自分でほとんど書き直すぐらいの気力が必要です。私は実際書き直しました。

ブログを（ここに）移行しました

Tue, 27 Oct 2020 06:45:04 GMT

ブログを移行しました。移行というか、Qiitaなど他サイトにあったものを集約しました。

移行した理由

理由の1つは、技術をQiitaで書いて、それ以外を別のサイトに書くのが面倒で集約したかったからです。 Markdownの解釈がサイトによって違ったり、そもそもWYSIWYGでしか書けなかったりすると、差異を考慮して記事を書くのがなかなか厳しい。仕事柄、マネジメントやビジネスについても書きたいことがいろいろあるので、それも多く書いていきたいとなるとブログを1つにまとめた方が早いなと。もちろん、読者層としては全然違うと思うので読む方にとっては不便だと思うのですが許してやってください。

もう1つの理由は、Qiitaと自分があまり相性が良くないと思うようになったことです。昔はRailsの記事とかを書いていて、あそこには一定Railsユーザーがいたのでそれでも良かったのですが、最近書きたいものはQiitaではマイナーなものばかりです。どちらかと言うとタイトルがキャッチーではない、外部から検索でたどり着くような詳細な技術トピックを書くことが多いので、であれば無理してQiitaで書くほどでもないかと思うようになりました。

何でできているか

Gatsbyのスターターを使っています。Leumというスターターです。今回はテーマではなくスターターを使いました。既にゴリゴリに改造してます。

ホスティングはNetlifyで行っています。記事の編集はNetlify CMSで、ドメインはNetlify DNSで管理しています。 Netlifyはall-in-oneさがすごいですね。別でVercelも使っていますが、ブログを作る程度で全部お任せしたい場合はNetlifyの方が好みです。

React.Suspenseの力を最大化する、GraphQLの次世代ディレクティブ @ defer と @ stream

Mon, 05 Oct 2020 08:47:00 GMT

ReactのSuspense、素敵ですよね。この記事ではGraphQLのワーキンググループで仕様の策定が進んでいる@deferと@streamについて解説します。@deferと@streamはReactのSuspenseの力を引き出す、注目すべきディレクティブです。

なお、これらのディレクティブの仕様はワーキンググループでほぼ合意できていますが確定した仕様ではないことに注意してください。

Suspenseは最高だ！

あるブログの記事の一覧ページを例に見てみます。記事一覧ページを表示するためのGraphQLのクエリは次のようになります。¹

query {
  articles(page: 1) { # 記事一覧（1ページ目）
    title # タイトル
    body # 文章（先頭の少しだけ表示）
    author {
      name # 著者名
    }
    like {
      count # イイねの数
      avatars {
        image # イイねしている人のアバター画像
      }
    }
  }
}

このクエリでは、まず記事の一覧（articles）があり、記事の中に著者（author）とイイね（like）があります。

ここでReactのSuspenseの典型的な利用例について簡単におさらいしておきましょう。 Suspenseを使うと、ページを一気に表示するのではなく、データが揃ったコンポーネントから段階的に表示していく処理を簡単に書くことができます。

Webサイトでページの一部にスケルトン（プレースホルダ）が表示されるのを見たことがありませんか？データがまだ表示できない時に、代わりに表示されるアレです。

https://material-ui.com/components/skeleton/ より

Suspenseはこういったコンポーネントの「待っている」状態の管理や表示の切り替えを担当します。 Suspenseを使うと、バックエンドに要求したデータ（またはクライアントのキャッシュにあるデータ）が揃ったコンポーネントから順に、スケルトンのUIから実際の表示に切り替えていく処理を簡単に書くことができます。

今回のブログの記事一覧の例で言うと、まず記事のタイトルなどのデータを最初に表示してから、その他のデータ（著者やイイね）を後で表示できるようになります。著者やイイねのデータがバックエンドから返ってきていない間は、そこだけスケルトンのUIを表示して読み込み中であることを表現できます。仮にバックエンドで”イイねの数”の集計が遅くても、それが足を引っ張りページ全体のレンダリングまで遅くなるという事態を避けられます。

ダメだキャッシュがない

ということで、Suspenseのおかげでユーザーを待たせずに重要なデータからいち早く表示できるようになりました。手軽にユーザー体験を向上させることができます！

…ちょっと待ってください。仮に記事一覧ページで使用できるデータのキャッシュが、ローカルに全くなかったとしましょう。² 私達がページの一部分でも表示するためには、データをバックエンドから取得しなければなりません。しかし、GraphQLのクエリをバックエンドに送ると、全てのデータが1回のレスポンスで返ってきます。そうなると部分的にページを更新しようにも、一気に全て表示する以外できません。

これは困りました。キャッシュなしで一部のデータだけを先に表示するためには、バックエンドからのレスポンスを分割する必要があるようです。

RESTやGraphQL（旧）の問題点

仕方がないので、クエリを3つに分割しましょう。

query Articles { # 記事一覧
  articles(page: 1) {
    id
    title
    body
  }
}

query ArticleAuthor { # 記事の著者
  article(id: $id) {
    author {
      name
    }
  }
}

query ArticleLike { # 記事のイイね
  article(id: $id) {
    like {
      count
      avatars {
        image
      }
    }
  }
}

Articlesクエリで記事一覧を取ってから、記事のidをArticleAuthorクエリ（著者）とArticleLikeクエリ（イイね）に渡して、データを取得するようにしました。このクエリをそれぞれバックエンドに送れば、複数のレスポンスが返ってくるのでSuspenseを使ってデータが揃った順に表示できます。この例ではGraphQLを使用していますが、基本的にRESTでも同じように一覧を取るAPIを叩いてから詳細なデータを取得します。

さて、これは動作しますが良い解決策というわけではありません。

まず、明らかに最終的なページを表示するまでの速度が低下しています。 ArticleAuthorクエリとArticleLikeクエリは引数に記事のidを取るため、Articlesクエリの結果が戻ってきてからでないとリクエストを送ることができません。 ³ そのため、ArticleAuthorクエリとArticleLikeクエリに含まれるデータを使用するコンポーネントのレンダリングは、1つのクエリで全て取得していた時よりも明らかに遅くなります。

また、複数のクエリに分割したことでリクエスト数が増えたためモバイルなどのバッテリーの消費が激しくなりますし、ArticlesクエリでDBから読み込んだ記事データにArticleAuthorクエリとArticleLikeクエリが再度アクセスすることになるためバックエンドの負荷も無駄に高くなります。

そもそも、このようなデメリットを避けるためにRESTではなくGraphQLを使用して1回でデータを取得できるようにしたという歴史的背景があるので、これでは時代が逆行しています。このような事態を避けるためにできることは何でしょうか。

データに優先度をつけてインクリメンタル配信する

Suspenseを使うと、ページを一気に表示するのではなく段階的に表示できます。しかしReactはページ全体をSuspenseで囲むのではなく、遅延表示して良いものだけをSuspenseで囲むように言っています。

ある機能が次の画面に必須なものではない場合は、それを <Suspense> でラップして、遅延読み込みさせてください。これにより、残りのコンテンツを可能な限り素早く表示できるようになります。逆に、あるコンポーネントがないと次の画面の表示自体が無価値であるという場合（例えば我々の例の <ProfileDetails>）、そのコンポーネントを <Suspense> で囲んではいけません。

ここから得られる洞察は、ページ内のコンポーネントには優先順位があるということです。重要なコンポーネントはすぐに表示させて、そうでないコンポーネントは遅延して表示させるべきです。この考え方はデータの配信にも言えます。データはコンポーネントで表示するためにあるので、ページ内のコンポーネントに優先順位がつくということは、ページ内で使用されるデータにも優先順位がつきます。

最初のクエリに話を戻しましょう。結論から言うと、我々の願いは、GraphQLのクエリを1回でリクエストして優先順位に従って複数のレスポンスを返してほしいということなのです。

query {
  articles(page: 1) {
    title # 優先する
    body # 優先する
    author { # 優先しない
      name
    }
    like { # 優先しない
      count
      avatars {
        image
      }
    }
  }
}

優先順位としては、まずはarticlesの1個目の記事のtitleとbodyがレスポンスとして返ってきて、その後に他の部分が遅延して返ってくると理想的ですね。

このように優先順位をつけて部分的にAPIからデータを返すことをインクリメンタル配信（Incremental Delivery、Incremental Data Delivery）と言います。

インクリメンタル配信を行う`@defer`と`@stream`

@deferと@streamはクエリ内でインクリメンタル配信を行う箇所を指定するためのディレクティブです。下記の例ではあくまで説明を簡単にするためのイメージとして記述しています。実際のクエリは最後に載せています。

query {
  articles(page: 1) @stream(initialCount: 1, label: "articlesStream") {
    title
    body
    author @defer(label: "articlesAuthorDefer") {
      name
    }
    like @defer(label: "articlesLikeDefer") {
      count
      avatars {
        image
      }
    }
  }
}

@stream(initialCount: 1, label: ...)は、配列のようなデータ構造から1つ（initialCountで指定した数）だけはすぐに返してもらい、その他は後で配信してくれれば良いという指定になります。 @defer(label: ...)は、そのブロックを最初の応答に含めず、後で配信してくれれば良いという指定になります。

2つのディレクティブに共通するlabelは、一意の値を指定します。これはGraphQLクライアントが後で配信されたデータの中身を識別するために使用します。

これらのディレクティブがあれば、クエリが返すレスポンスを分割し、優先順位をつけて返してもらえるようになります。

1つのリクエスト、複数のレスポンスの実装

ところで、インクリメンタル配信はどうやって実装するのでしょうか。1つのリクエストを送って、複数の結果を返すようなことはHTTPで実現できるのでしょうか。

HTTP1.1ではTransfer-Encodingというヘッダがあり、Transfer-Encoding: chunkedを指定することで複数のチャンク（塊）でデータを返すことができます。これはもともとContent-Lengthで指定するデータの長さ（大きさ）の計測を避けるためのヘッダなのですが（データの大きさが分からなくてもチャンクで分割して返し始めることができます）、GraphQLではチャンクを順次返す仕組みを使ってインクリメンタル配信を実現します。

現在の進捗

GraphQLの仕様を検討するワーキンググループで@deferと@streamの仕様の策定が進められています。仕様自体はほぼ合意が取れている状況です。バックエンドの実装が必要なタイプの仕様なので、リファレンス実装としてgraphql-jsの実装が先行しています。

ただし、そもそもReactのSuspenseとデータフェッチの組み合わせがいつ実験的機能でなくなるのかも謎なので、早くても普通に使えるようになるのは2021年になってからでしょう。2022年にならないことを祈ってます。

おまけ：実際のクエリ

最後に、現在ワーキンググループで検討されているRFCに沿って今回使用したクエリを記述します。

query {
  articles(page: 1) @stream(initialCount: 1, label: "articlesStream") {
    title
    body
    ...ArticlesAuthor @defer(label: "articlesAuthorDefer")
    ...ArticlesLike @defer(label: "articlesLikeDefer")
  }
}

fragment ArticlesAuthor on Article {
  author {
    name
  }
}

fragment ArticlesLike on Article {
  like {
    count
    avatars {
      image
    }
  }
}

現在策定されている仕様では、@deferはフラグメントにしか使用できません。 ReactとGraphQLを結びつけるRelayではフラグメントとコンポーネントはほぼ1対1です。コンポーネントのレンダリングを遅延させて良いのであれば（Suspenseで囲むなら）、@deferをコンポーネントのフラグメントにつけるという流れになると思います。

今回のGraphQLのスキーマは説明を簡単にするために通常ではありえないスキーマ設計になっています（like.countなど）。真似しないでください。
↩
Relay、SWR、React Queryなどを使用することで、キャッシュに存在しているデータを先に表示するコードを簡単に書けます（ただしexperimentalのものがほとんどです）。むしろキャッシュ機構を持つデータフェッチライブラリがないとSuspenseの利用は大変だと思います。
↩
authorやlikeもarticlesで取ればウォーターフォールが発生しないのではと思ったかもしれません。確かに発生しませんが、DBからのデータ取得に無駄が多いという側面もありますし、現実問題として最初のarticlesを取った時と最後のarticlesを取った時で、記事が削除や追加されていない保証はないですから、authorやlikeと記事一覧のズレを考慮するようなカオスなクライアント実装になると思います。
↩

GraphQLを検討中のあなたに送るQ&A集

Sat, 03 Oct 2020 15:00:59 GMT

世間でGraphQLが流行っているから採用検討しているものの、いろいろ調べたけど正直実感が湧かない…という方もいますよね。そこでフロントエンドとバックエンドの両方の観点から、いくつかの典型的な疑問とその回答をご用意しました。

これは私が質問された時に答えている内容をまとめたものですが、何かの参考になれば幸いです。

既にGraphQLについて何となく知っている、例えば「QueryとMutationなるものがあるらしい」ぐらいは理解していると想定して書いています。何が書いてあるか分からない項目は読み飛ばしてください。

はじめに編

GraphQLの素晴らしいところは何ですか

最も素晴らしいのは、GraphQLクライアントによりフロントエンドのDX（開発時の体験）が圧倒的に良くなる点です。

フロントエンド編

フロントエンドにどんなメリットがありますか

GraphQLクライアントであるApolloやRelayが使えることがメリットだと思います。どのGraphQLクライアントを使用するかによって多少変わりますが、基本的にはデータの取得や更新においてバグりやすい処理が減ります。 DOMはjQueryからReactなどに移行することで大幅に宣言的に書けるようになりましたが、同じ現象がデータの取得や更新でも起こります。宣言的なデータ管理といったところです。どこまで宣言的に書けるかはGraphQLクライアントによります。また、データに自動的に型が付くので開発しやすいと思います。

基本的にはコードも減ってバグも減るので、生産性は上がると思います。

Reduxなどの状態管理のソフトウェアを使う必要がありますか

必要ありません。ApolloやRelayなどのデータ管理を行うGraphQLクライアントを使う場合は同様の処理をやってくれます。 API経由以外のローカルステートもApolloとRelayともに管理できます。

とは言え、独自の観点からReduxと組み合わせて使っている人もいますので、組み合わせられないわけではないです。

ApolloとRelayどちらが良いですか

一長一短です。すごく単純化すると、あなたがReactを使っていて、TypeScriptをstrictで使うような機械に極力任せたい（そのために努力できる）派閥の人ならRelayが良いかもしれません。そうでないならApollo一択。

他に有名なGraphQLクライアントはありますか

Apollo、Relayに次いで有名なのはurqlです。説明できるほど詳しくありませんが、ApolloやRelayよりシンプルに使えると思います。 Apolloのハマりやすさ、Relayの厳しすぎる要件が嫌な人はurqlを使っている印象です。

TypeScriptと相性は良いですか

はい。型がある点がGraphQLメリットの1つなので、間違いなく便利に使えます。他に型のあるAltJS（例えばReasonML）とも相性は悪くありません。そちらの方が最高と言ってる人もいるくらいですが、入門者にとっては情報量や品質の観点からTypeScript以外を試すのは現実的ではないと思います。

一回で色々なオブジェクトを取得するのでUIの表示が遅くなりませんか

たくさんの情報をクエリで一気に要求しているとAPIのレスポンスは当然遅くなります。バックエンドに魔法の技術はありません。困ったら次のことを検討してください。

UIとしてスケルトンを表示してください
可能な限りGraphQLクライアントのキャッシュを活用してください
クエリを分割してください。可能な限りネストを浅くしてください
そのうち@deferが使えるようになると思うので検討してください

現実問題として、バックエンドでのSQLのチューニングはRESTよりやり辛くなってます。パフォーマンスによるユーザー体験の影響はREST時代よりもクライアントの責任が増えていると理解してください。

バックエンド編

バックエンドにどんなメリットがありますか

エンドポイントを増やさなくて良い、マイクロサービスでBFFを組みやすい、などが代表例だと思います。ただ、これは個人的な意見ですが、APIの要件はフロントエンドの都合に合わせる時代だからGraphQLを選択している程度にしか考えていません。もちろん幸せになったバックエンドエンジニアの話も調べたら出てくると思うので、そちらをご覧いただければと思います。

APIに型をつけるという観点で、GraphQLとXXX（好きなソフトウェア）と違いはありますか

たぶんないです。RESTのAPIに型をつけるソフトウェアを使って、GraphQLの型付けの性質と同じようなものを作ることは可能です。これは型付けだけでなく、あらゆるGraphQLの特徴は論理的には別の技術で個別に代替できると思います。 GraphQLの良いところは、いくつかの特徴が組み合わせで固定されていて、エコシステムがその特徴を前提としたツールを構築できる点にあると思います。 FacebookのオレオレAPI仕様に名前を付けて標準化したことで、みんなが乗っかれたことが良かったと思ってます。

スキーマファーストとコードファーストのどちらが良いですか

コードファーストだと思いますが、断言できません。 GraphQLの世界で強い影響力を持つApolloはスキーマファーストを主導してきました。一方でApolloと利害関係のないフレームワークでは近年コードファーストをメインに採用する傾向が強まっています。正直、今が一番どうなるのか分からない時期です。

私はコードファースト派です。実運用でスキーマだけ先に書いてもメリットを得るのは難しい、バックエンドでスキーマから生成した型を使ってモデルを書くのは最悪のDXだ、などと思ってますが、たくさんの論争があるのでここで言い切るのは難しいです。

CDNでキャッシュが効かないと聞きましたが本当ですか

はい。これも多くの論争がありますが、要約すると「諦めて他のことをした方が生産的」になります。

まず、ブログのような大部分が静的なページを運営している場合はCDNが変わらず必要だと思いますが、それはそれで（APIのレスポンスではなく）サーバーサイドでレンダリングしたページをCDNのキャッシュにのせてもらって、GraphQLとは関係なくよしなにして下さい。以下はそれ以外のケースについて話します。

この問題はGraphQLではPOSTメソッドでやり取りを行うので、（GETを対象にした一般的な）CDNではキャッシュが効かせにくいという話なのですが、一応仕様的にはGraphQLはGETを使用できます。また、GraphQL対応のCDNも存在しています。

ただ、いくつかの点で考えると、やはりCDNでキャッシュを効かせられるように頑張る労力にリターンが見合うかはちょっと…。

GraphQLではクライアントでキャッシュを効かせる世界観なので必要性は薄め
RESTfulのようにリソースとリクエストが対応するわけではないので、仮に同じオブジェクトを取得していても様々なリクエスト（query）の形があってキャッシュが効きにくい
CDNでキャッシュするとクライアントと2重でキャッシュのレイヤが生まれるため、複雑怪奇なバグに見舞われる可能性がある

もちろん、画像や動画は別のエンドポイントで引き続きCDNのキャッシュを使用してください。 APIのレスポンスを高速にしたい場合はCDNではなくサーバーに到達して以降の何かのキャッシュを頑張った方が吉。

N+1は発生しますか

何も考えないと発生します。 GraphQLではコンテキスト（queryの形）によって関連するテーブルを読み込んだり読み込まなかったりするので、我々が事前にJOINしたSQLを組み立てるのは容易ではありません。 RESTの決まったレスポンスのために手動でゴリゴリにチューニングしたSQLより速くなることはないと理解しつつ、dataloaderのような仕組みを使ってください。

1発であらゆるオブジェクトが取得できるって負荷やばくないですか

やばいので、複雑度と深さで計算してクエリを制限します。 GraphQLは1発であらゆるオブジェクトを取得するためのものと勘違いされてる節がありますが、1発でアプリケーションに必要な全てのデータを取得するのはさすがに非現実的です。適切にクエリは分けてください。まずはページ単位で分ける感じで。

エラーが発生したのに200を返すのはおかしいと思います

GraphQLではレスポンスコードは常に200で、一般的にはエラーはレスポンスボディ（のJSON）のerrorsに入れて返します。

まずこの仕組みの利点から説明すると、利点はエラーが一部発生しても一部のデータは返すことができる点です。 GraphQLでは1回のリクエストで多くのデータを取得できますが、一部でエラーが発生しても返ってきているデータがあるならそれをレンダリングできます。例えばBFFでまとめているマイクロサービスで一部がダウンしている状況でも、動いている部分だけ返すことができますし、逆にこれができないとクエリは丸ごと失敗するのでフロントエンドから見ると全体がダウンしているように見えてしまいます。

とは言え、個人的にはサーバーサイドの実装を手抜きしてMutationのバリデーションエラー以外は普通に401とか500で全体を失敗させて返すこともありますし、それでハンドリングできます。

どうやって認証しますか

特にRESTと変わりません（異なる方法でも実装できますが）。ヘッダのAuthorizationに認証情報をのせて、それをいつも通りに処理してください。

RESTのAPIと共存できますか

はい。色々やり方があると思います。

BFFでAPIをまとめてGraphQLだけにすることもできますし、GraphQLとRESTの両方のAPIを持つサーバーにクライアントからアクセスすることもできます。 GraphQLクライアントからRESTのAPIが叩けるかは使用しているGraphQLクライアントによりますが、使えないなら普通にRESTのAPIが叩けるライブラリ（axiosとか）を使ってください。

既存の外部システムと連携する部分などは移行が難しいでしょうし、GraphQLだけで作れないこともあるでしょう。例えば、私はフロントエンドで画像を処理するライブラリを使用していて、その中にサーバーに画像をアップロードする機能があるのですが、GraphQLに対応していないのでその部分のバックエンドは普通にRESTで書いてます。ただし、当該処理がDBと関係ないので許されるという側面が多大にあり、通常はGraphQLで書けるだけ書くのが無難です。

Relay Server Specificationに準拠する必要がありますか

ケースバイケースです。 Nodeインターフェース、Global Object Identification、Connectionベースのページネーションのことを指して、Relay Server Specificationと言います。これらはフロントエンドでコンポーネント指向のアプリケーション（Reactとか）を書いてある場合は提供した方が良いと個人的には思います。コンポーネントにデータをバインドしやすくなります。Relayを使う場合は必須です。あとで導入するのはかなりの痛みが伴いますので、最初によく検討してください。

`node(id)`フィールドは神APIではないですか

その通りです。あらゆるものと結合している、悪い意味での神API（ゴッドAPI）です。 node(id)フィールドはユニークなidであらゆる単一のオブジェクトを取得できるメソッド的なものです。あらゆるオブジェクトが取得できるので、公開されているあらゆる型（モデル、テーブル）の情報が引けます。なのでバックエンドのコード上ではnode(id)のリゾルバからは様々な依存関係ができます。幸いなことに単方向の依存関係ですが。 RESTではありえない考え方ですが、ここにREST的な意味での正しい答えはありません。まごうことなき神APIが目の前にあるだけです。

Connectionベースのページネーションを調べましたが意味が分かりませんでした

たぶんConnectionとEdgeという謎のオブジェクトがページネーションを複雑化させてるように見えるんですよね。分かります。こちらをご覧ください。

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

Fri, 25 Sep 2020 08:42:00 GMT

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信者寄りなのは否めない。

実際、私はRelayを使っていてもバックエンドはapollo-serverを使ってますし、subscriptionにはsubscriptions-transport-wsを使ってます。
↩

Nodeインターフェースの魔法

Sat, 29 Aug 2020 15:00:00 GMT

Relay入門シリーズも最後となりました。この翻訳記事ではGraphQLのベストプラクティスの1つであるGlobal Object IdentificationとNodeインターフェースの解説になります。 Relayにとっては、fragmentと同じくあらゆる便利機能を生み出す源泉となっている仕組みです。ぜひご覧ください！

（原文）

Relay入門シリーズ（全4記事）
Relay：あなたのために泥臭い仕事をしてくれるGraphQLクライアント
GraphQLでのConnectionベースのページネーション
Relayを使って最小限の努力でページネーションをする
Nodeインターフェースの魔法（本記事）

この連載は、Gabriel NordebornとSean Groveが執筆しています。GabrielはスウェーデンのITコンサルタント会社Arizonのフロントエンド開発者でありパートナーでもあり、長い間Relayを利用してきました。SeanはサードパーティのAPIをGraphQLで統一するOneGraph.comの共同創業者です。

GraphQLの公式サイトは最近、ベストプラクティス集に「Global Object Identification（グローバルなオブジェクトの識別）」というセクションを追加しました。この記事では、Global Object Identificationとは何か、なぜそれが有用なのか、そしてそれによってどのような種類の開発者体験が可能になるのかについて掘り下げていきます。

Global Object Identificationとは何か？

GraphQLのGlobal Object Identificationには2つの意味があります。

グラフ内の個々のオブジェクトは、型を超えてグローバルに一意なIDで識別できます。つまり、異なる型であっても、2つのオブジェクトが同じIDを持つことはできません。
idを持つ任意の1つのオブジェクトはそのidだけでqueryできます。これは後ほど詳しく説明するNodeインターフェースを介して行われます。

これにより、ライブラリは開発者が自分で実装したり管理したりしなければならないいくつかのことを以下のように安全に自動化することができます。

すべてのオブジェクトが一意のIDを持っているので、GraphQLフレームワークは任意のオブジェクトのキャッシュを自動的に更新することができます。
オブジェクトの新しいフィールドや更新されたフィールドを取得する必要がある場合、私たちが知る必要があるのは、そのオブジェクトのGraphQLの型とそのidだけです。

この2つのポイントがなぜ素晴らしい開発者体験を可能にするのかについて、詳しく説明していきましょう。

そもそも`Node`インターフェースとは何か？

Nodeインターフェースを実装しているスキーマでは、nodeと呼ばれるQueryオブジェクトのトップレベルのフィールドを見ることができます。nodeはidという単一の引数を取り、単一のフィールドidを返します。

「何だそれ」と思いましたか？初めて見ると確かに少し不思議な感じがしますよね！

query NodeInterfaceExample1 {
  gitHub {
    node(id: "MDQ6VXNlcjM1Mjk2") {
      id # 予想通り、これは"MDQ6VXNlcjM1Mjk2"になります
    }
  }
}

nodeはインターフェースなので、スキーマ内のすべてのGraphQLオブジェクトが実装しており、idを介してオブジェクトを取得することができます。

query NodeInterfaceExample2 {
  gitHub {
    node(id: "MDQ6VXNlcjM1Mjk2") {
      id
      ... on GitHubUser {
        login # "sgrove"
        followers {
          totalCount # 9000人以上!!!!
        }
      }
    }
  }
}

なぜそれが役に立つのか？

これが意味するのは、あるオブジェクトのidとGraphQLの型を知っていれば、私たちはいつでもオブジェクトを取得する方法が分かっているということです。この代替案としては次のようなものができるかもしれません。

query WithoutInterfaceExample {
  gitHub {
    user(login: "sgrove") {
      login
      followers {
        totalCount
      }
    }
  }
}

しかしこのqueryには2つの課題があります。これらの課題は開発者にとっては余分な作業が多くなる、そつまり何かを間違えてしまう機会が増えることを意味しています。

上記の方法でGitHubUserを見つけようとしても、idという引数は受け付けずにloginという引数のみを受け付けます。つまり、たとえばownerIdの値を既に持っていたとしても、loginの値を追加で知る必要があるということです。あらゆる種類のオブジェクトで異なるキーを使って探すことになる可能性があるため、ますます面倒なことになってしまいます。
仮にloginの値を持っていたとしても、追加で必要なフィールドがあった時に、私たちはネストされた項目（この場合はgitHub.user）を使って複雑になる可能性のあるqueryを構築しなければなりません²。

結局のところ、これらは両方とも暗黙的に分かっていることです。私たちはそれらを開発者として知っており、頭の中にその知識を持っています。それはつまり、コンピューターとツールはその知識を持っていないということです。

しかし、もし私たちのツールがidを与えたオブジェクトを探す方法を知っていれば、それは素晴らしい方法で私たちを助けてくれるでしょう。

これはバックエンドの負荷を軽減することにもなります。queryの中で深くネストされているノードを再取得する必要がある場合は常に、バックエンドは対象のノードにたどり着くために、対象のノードより上のすべての階層を解決（データを取得）しなければなりません。しかし、idを取得して単一のノードを直接解決することができれば、そのような負荷はなくなります。

なぜグローバルに一意なIDなのか？整数で十分では？

Nodeインターフェースを使えば、どんなオブジェクトでもidで検索できるようになります。いいですね！ただ、これはAPI全体の中で2つのオブジェクトが同じidを持つことができないことを暗示しています。

余談：この仕組みは最初は難しいと思うかもしれませんが、どんなスキーマでも簡単にこれを行う方法があるとすぐに分かるようになります。

idフィールド（User.idやPost.idなど）を持つすべてのGraphQLオブジェクトは、他のGraphQLオブジェクトが持っていない一意のIDを持たなければなりません。次のqueryを例に考えてみましょう。

query FirstUserAndFirstPost {
  user {
    id
  }
  post {
    id
  }
}

多くのデータベースではインクリメントする整数をidとして使用するのが一般的なので、次のようなレスポンスを期待するかもしれません。

{
  "data":{
    "user":{
      "id":1
    }
    "post":{
      "id":1
    }
  }
}

しかしNodeインターフェースと組み合わせるとこれはうまくいきません。例えば、投稿（post）のidを持っていて、いくつかの追加フィールド（titleなど）を取得したいとします。その場合、次のようなqueryを実行できるかと思います。

query NodeInterfaceExample3 {
  node(id: 1) {
    id
    ... on Post {
      title
    }
  }
}

しかし、1のidで探すことができるオブジェクトが2つも存在しています！戻り値のオブジェクトがUserになるのかPostになるのかは今のところ分かりません。

がっかりしないでください！簡単な解決策があります！

内部的には整数をIDに使い続けつつ、グローバルに一意なIDを持つにはどうすればいいのでしょうか？ GitHubで使われているIDの例を見てみましょう（APIは美しく、Relayとの互換性もあります！）。node(id: "MDQ6VXNlcjM1Mjk2")というqueryを使ってアクセスできます。ここで使われているIDを見てみましょう。

> atob("MDQ6VXNlcjM1Mjk2")
"04:User35296"

なんと、整数が入ってますね³。

基本的にはnodeIdを構築するの手法は以下のようになります。

`base64Encode(${apiVersion}:${GraphQLObjectTypeName}${ObjectId})

よってAPIバージョン1のpostとuserについては、次のようになると期待します。

"MDE6UG9zdDE=" # "01:Post1" にデコード
"MDE6VXNlcjE=" # "01:User1" にデコード

競合があった前のnodeの例に戻って、新しいIDを使用すると次のようになります。

query NodeInterfaceExample4 {
  node(id: "MDE6UG9zdDE=") {
    id
    ... on Post {
      title
    }
  }
}

これでnodeのリゾルバはidをbase64でデコードし、idが1のPostオブジェクトを探していることが分かるため、正しいオブジェクトを返すことができるようになりました。

グローバルidにAPIのバージョンをprefixとしてつけるのは、必要になった時に既存のグローバルidを壊さずに後でエンコード方法を変更できるようにするためです。これは実質的には何もしなくても獲得できるちょっとした柔軟性です。 ⁴

もしまだピンときてない場合（特に、なぜidがそのオブジェクトのデータベース上のID以外のものになるのか理解できない場合）、GraphQLの型のidフィールドを次のように考えると良いかもしれません。つまりGraphQLの型のidを見るときは、実際にはデータベースのテーブルではなくグラフのノードを見ているということです。このように考えると、GraphQL型のidをグローバルに一意にすることはより意味のあることです⁵。

これは何を可能にするのか？

最初に見たように、ほとんどのスキーマでは、トップレベルのnodeフィールドを使用していなくても、ほとんどのものは単一のアイテムを解決する（探す）何らかの方法をすでに持っています。ではなぜnodeフィールドが重要なのでしょうか？それは単に解決をより便利にするためでしょうか？

もちろんそれも役立ちます。しかし、真の力は標準化から生まれます。

考えてみれば、スキーマにpostById(id: ID!)というトップレベルのフィールドがあって、それが実際にidでPostを解決していたとしても、スキーマの作成者以外にはそのフィールドが実際に何をしているのかを知る方法はありません。postByIdの意味を解析して、かつ、実際に「単一のPostを与えられたidで探す」という意味であることを推論しなければ、外部ツールやフレームワークはその特定のフィールドが何をするのかを安全に仮定することができません。1つのPostを解決するフィールドは、次のようにいくつでも持つことができます。postByDatabaseId(id: ID!): PostやmostLikedPost(id: ID!): Post、latestPost(id: ID!): Postなどなど。こうなると外部ツールが単一のPostを再取得する際にどのフィールドを使用するかを安全に仮定することができなくなります。

しかし、Nodeインターフェースは公式のGraphQLのベストプラクティスであるため、フレームワークやツールはその上に構築することができ、それを実装する人は誰でも恩恵を受けることができます。そしてそれを使って構築できるものには、いくつかとてもクールなものがあります。Relayの具体的な例を見てみましょう。

ページネーションqueryの自動生成

Relayの最新版（今はRelayとのみ呼んでいますが、一般的にはRelay Modernとして知られています）では、Nodeインターフェースを介して任意のGraphQLオブジェクトを再取得できるため、データの再取得やページネーションのためのqueryを自動的に生成することができます。これにより、非常に人間工学的な開発体験を実現できます。基本的にRelayでは次のようにします。

fragment UserFriendsList_user on User {
  id
  friends(first: $first, after: $after) {
    edges {
      node {
        firstName
        lastName
      }
    }
  }
}

このようなfragmentがあったら、このためのページネーションqueryを下記のように自動的に生成します。

query UserFriendsListPaginationQuery($id: ID!, $first: Int!, $after: String) {
  node(id: $id) {
    ... on User {
      id
      friends(first: $first, after: $after) {
        edges {
          node {
            firstName
            lastName
          }
        }
      }
    }
  }
}

…なぜこんなことができるかと言うと、ページネーションで定義しているUserFriendsList_userfragmentの型であるUserがNodeインターフェースを実装していることを知っているため、idを使って再取得できるということが分かっているからです。

ページネーションの対象となるUserが最初のquery内でどこにいたかは関係ありません。Nodeインターフェースがあれば、そのUserのidさえあればRelayは任意のUserを再取得することができます。

Relayでのページページネーションについてはこちらの記事に書いているので参照してみてください。

典型的な「もっと見る」機能のためのqueryの自動生成

同様に、Relayを使えば定番の「もっと見る」機能⁶を簡単に構築することができます。Relayを使えば、以下のようにできます。

fragment ProfilePage_user on User {
  id
  name
  avatarUrl
  bio @include(if: $showMore)
}

…そしてRelayはこのフラグメントを再取得できるようにするqueryを生成しますが、そこでは$showMoreをtrueに設定してbioをフィールドに含めます。

「もっと見る」機能の構築は、基本的にはユーザが「もっと見る」ボタンを押したときにrefetch({showMore: true})を実行するだけのシンプルなものになります。残りの処理はRelayが行います。これは、Userがquery中のどこにいるかに関係なく、NodeインターフェースでUserのidを使って再取得する方法を知っているためにできることです。

まとめ

グローバルに一意なIDとNodeインターフェースがなぜ良いアイデアなのか、理解していただけていたら幸いです。Relayはこの仕組みをうまく活用していますが、これは公式のGraphQLのベストプラクティスなので他のツールでもその上に構築することができます。

訳注：sgroveはこの記事の作者の名前、Sean Groveのハンドルネーム。
↩
訳注：後述されますが、idを使ってオブジェクトを取得できるのであればグラフから必要なところだけオブジェクトの取得ができるため、不要な上位階層を解決する（取得する）必要がなく、基本的にはネストが浅くなります。
↩
訳注：atob関数はBase64をデコードするための関数です。「githubで使うidをBase64でデコードしたら整数が入ってるように見えるんですけど？」ということです。 https://developer.mozilla.org/ja/docs/Web/API/WindowBase64/Base64\_encoding\_and\_decoding
↩
標準的な実装であるgraphql-relay-jsはidと型名のみで構成しています https://github.com/graphql/graphql-relay-js/blob/3bd6838d41808674b97d024210c11937881b5ffd/src/node/node.js#L90 ただ、idを必ず一意にしなければならない関係上、このidのエンコード方法には自由度が求められます。githubの例のようにAPIバージョンが違えば別の値が返るようにしたい、などです。そのため型名とidで構成すれば絶対に大丈夫とは（世界中のユースケースで）言い切れません。
↩
DB（一般的なRelational Database）の場合はテーブルに名前がついていて、その中でidがユニークになることが求められます。GraphQLでは様々な型が1つのグラフの中に入っているので、その中で1つをIDだけで指し示すためにはグラフ全体で一意のIDが必要になるということです。
↩
ここで言う「もっと見る」とは、ページネーションで残りのアイテムをロードすることを指すのではなく、文章の頭だけ表示されていてクリックすることで全体が読めるようになるようなUIのことを指しています。「詳細を見る」のような感じです。
↩

Relayを使って最小限の努力でページネーションをする

Fri, 28 Aug 2020 15:00:00 GMT

GraphQLのConnectionベースのページネーションは確かに良いアイディアですが、Relayを使うことでこの仕様を最大限活用し、重複するコードを限界まで排除できます。この翻訳記事ではRelayがどのようにConnectionベースのページネーションを処理するのか、詳細を解説していきます。

（原文）

Relay入門シリーズ（全4記事）
Relay：あなたのために泥臭い仕事をしてくれるGraphQLクライアント
GraphQLでのConnectionベースのページネーション
Relayを使って最小限の努力でページネーションをする（本記事）
Nodeインターフェースの魔法

この連載は、Gabriel NordebornとSean Groveが執筆しています。GabrielはスウェーデンのITコンサルタント会社Arizonのフロントエンド開発者でありパートナーでもあり、長い間Relayを利用してきました。SeanはサードパーティのAPIをGraphQLで統一するOneGraph.comの共同創業者です。

ページネーション。それは誰もが最終的に辿り着くもので、そして正直に言えば楽しいものではありません。この記事では、いくつかの規則に従えば、Relayでのページネーションは楽しくないかもしれませんが簡単で人間工学に基づいたものであることを紹介します。

この記事では、フィルタを使用せずに前方へのページネーションのみを行うシンプルなページネーションに焦点を当てます。しかし、Relayでは後方へのページネーションも同様に簡単に行うことができ、フィルターも美しく処理できます。この2つについてはこちらをご覧ください。

また、Relayでのページネーションを最大限に実現するためには、お使いのGraphQLサーバが以下の2つのGraphQLのベストプラクティスに従う必要があります。

グローバルなオブジェクトの識別（Global object identification）とNodeインターフェース。こちらの記事でも紹介しています。
Connectionベースのページネーション。こちらも記事がありますのでぜひ読んでみてください。

この記事ではまず身近なアプリの例を紹介し、次に必要なページネーションを実装する上での課題を説明します。そして、これらの課題に対するRelayのソリューションを説明します。

GraphQLクライアントでは、通常どのようにページネーションが行われるのか？

通常、ページネーションは次のように構成されます。

通常は何らかのquery（典型的には現在見ているビューのメインのquery）から、何らかの形式でアイテムの最初のリストを取得します。このqueryには、通常はページネーションしたいリストのアイテムに加えて、他にも多くのものが含まれています。
リストのアイテムを 追加で 取得できる別の queryを定義します。
2で定義した別の queryと 最初の queryから取得した適切なカーソルを使用して、次のページを取得します。このとき、必要なアイテムの数も指定します。
そして、 最初の リストのアイテムに新しいアイテムをマージするコードを書いて、ビューを再レンダリングします

それではやってみましょう。ユーザーのプロフィールページのすべてのデータを取得する典型的な例です。

query ProfileQuery($userLogin: String!) {
  gitHub {
    user(login: $userLogin) {
      name
      avatarUrl
      email
      following {
        totalCount
      }
      followers(first: 5) {
        totalCount
        edges {
          node {
            id
            firstName
            lastName
            avatarUrl
          }
        }
      }
    }
  }
}

このqueryは、私たちが気になる2つのデータのグループを取り出します。

名前やメールアドレスなどのユーザーのプロフィール情報。
それぞれいくつかのフィールドを持つフォロワーのリスト。まず最初の5人のフォロワーを取得します。

最初のqueryができたので、次の5人のフォロワーを取得するためにページネーションしてみましょう（人気のあるユーザーがそこにいるかも！）。

元のqueryを再利用しようとしても十分ではない

最初に気づくことは、ページネーションのために定義した最初のqueryを再利用すべきではないということです。私たちには新しいqueryが必要です。なぜなら…

ユーザーの全てのプロフィール情報を再取得したくありません。ユーザーのプロフィール情報はすでに取得しており、再度取得するのはコストがかかります。
最初の5人のフォロワーだけから始めて、実際のページネーションに追加のロードを委任したいと思っています。なので最初のqueryにページネーションのための変数を追加することは冗長ですし、不要な複雑さが増してしまうように感じます。

そこで、新しいqueryを書いてみましょう。

query UserProfileFollowersPaginationQuery(
  $userLogin: String!
  $first: Int!
  $after: String
) {
  gitHub {
    user(login: $userLogin) {
      followers(first: $first, after: $after) {
        pageInfo {
          hasNextPage
          endCursor
        }
        edges {
          node {
            id
            firstName
            lastName
            avatarUrl
          }
        }
      }
    }
  }
}

これでいきましょう！これでページネーションに必要なものはすべて揃いました。素晴らしい。しかし、ここで注意すべきことがいくつかあります。

このqueryを手書きで書く必要があります。
フォロワーをページングしたいユーザーがわかっていても、変数を使ってその情報¹を再度queryに与える必要があります。これは最初のqueryでどのようにユーザーを選択したかと正確に一致させる必要があり、間違えないようにする必要があります。
手動で次のカーソルをqueryに指定してページネーションする必要があります。指定するカーソルはこのビューでは常に最後のカーソルになることが分かっていますが、手動でやる必要があります。

このような作業を手動でしなければならないのは残念なことです。もしフレームワークがページネーションのqueryを生成して、毎回同じことになるこれらのステップを処理できるとしたらどうでしょうか…？

そう、nodeインターフェイスとConnectionベースのページネーションを使えば、Relayはやってくれます！

Relayでのページネーション

ここでは、Relayでのページネーションの仕組みを先ほどの例と同様にシンプルなプロフィールページを使って説明しましょう。プロフィールページにはユーザに関する情報が掲載されており、ユーザの友達のリストも掲載されています。友達のリストはページネーションができるものにしておきましょう。

// Profile.ts
import * as React from 'react';
import { useLazyLoadQuery } from 'react-relay/hooks';
import { graphql } from 'react-relay';
import { ProfileQuery } from './__generated__/ProfileQuery.graphql';
import { FriendsList } from './FriendsList';

interface Props {
  userId: string;
}

export const Profile = ({ userId }: Props) => {
  const { userById } = useLazyLoadQuery<ProfileQuery>(
    graphql`
      query ProfileQuery($userId: ID!) {
        userById(id: $userId) {
          firstName
          lastName
          ...FriendsList_user
        }
      }
    `,
    {
      variables: { userId },
    },
  );

  if (!userById) {
    return null;
  }

  return (
    <div>
      <h1>
        {userById.firstName} {userById.lastName}
      </h1>
      <h2>Friends</h2>
      <FriendsList user={userById} />
    </div>
  );
};

これがプロフィールページを表示するためのルートのコンポーネントです。ご覧のように、これはqueryを作成して、このコンポーネント自身を表示するための情報（firstNameとlastName）を要求し、そしてFriendsList_userのfragmentをqueryに含みます。fragmentにはFriendsListコンポーネントをレンダリングできるようにするために必要なUser型のデータを含んでいます。

コンポーネントの真のモジュール性の力

今のところどこにもページネーションは見当たりませんよね？待ってください、すぐ来ますから。ただ、その前に気をつけてほしいことがあります。<FriendsList />がページネーションを行っていることをこのコンポーネントが知る必要はありません。これが Relay のもう一つの強みです。このことがもたらす意味をいくつか挙げてみましょう。

どんなコンポーネントでも、既にレンダリングしているコンポーネントを弄らずに、ページネーションを独立して導入できます。「そんなことか」と思いましたか？ 2週間の急ぎのプロジェクトでなくても、ページネーションを導入する必要のあるコンポーネントがかなり多くの画面に分散されている場合、きっとそうは思わないでしょう。
ProfileQueryは変数のような不要なものを定義する必要はなく、<FriendsList />がページネーションできるようにするだけです。
既に仄めかされていますが、これらの特徴はコンポーネント間に暗黙の（または明示的な）依存関係が作成されないことを意味します。つまり、何かを壊す危険を冒すことなく、コンポーネントを安全にリファクタリングしたりメンテナンスできます。高速に作業ができるということです。

ページネーションを行うコンポーネントの構築

下記はFriendsListコンポーネントで、これが実際にページネーションを行っているものです。こちらは少し濃い内容になります。

// FriendsList.ts
import * as React from 'react';
import { usePaginationFragment } from 'react-relay/hooks';
import { graphql } from 'react-relay';
import { FriendsList_user$key } from './__generated__/FriendsList_user_graphql';
import { FriendsListPaginationQuery } from './__generated__/FriendsListPaginationQuery_graphql';
import { getConnectionNodes } from './utils/getConnectionNodes';

interface Props {
  user: FriendsList_user$key;
}

export const FriendsList = ({ user }: Props) => {
  const { data, hasNext, loadNext, isLoadingNext } = usePaginationFragment<FriendsListPaginationQuery, _>(
    graphql`
      fragment FriendsList_user on User
        @argumentDefinitions(first: { type: "Int!", defaultValue: 5 }, after: { type: "String" })
        @refetchable(queryName: "FriendsListPaginationQuery") {
        friends(first: $first, after: $after) @connection(key: "FriendsList_user_friends") {
          edges {
            node {
              id
              firstName
            }
          }
        }
      }
    `,
    user,
  );

  return (
    <div>
      {getConnectionNodes(data.friends).map((friend) => (
        <div key={friend.id}>
          <h2>{friend.firstName}</h2>
        </div>
      ))}
      {hasNext ? (
        <button disabled={isLoadingNext} onClick={() => loadNext(5)}>
          {isLoadingNext ? 'Loading...' : 'Load more'}
        </button>
      ) : null}
    </div>
  );
};

ここにはたくさんのことが書かれていて、これからすべてを少しずつ分解していきますが、まずはどれだけ手作業が少ないかに注目してください。その点について、いくつか見ていきましょう。

ページネーションに使用するカスタムqueryを定義する必要はありません。Relayが自動的に生成してくれます。
ページネーションで次のカーソルを追跡する必要はありません。Relayが自動的にやってくれるので、私たちがミスすることはありません。
ページネーション結果をストアにあるものとマージするためのカスタムロジックは不要です。Relayが代行してくれます。
ロードの状態を追跡したりロード可能なアイテムの数が増えたかどうかを確認したりするために、余計なことをする必要はありません。Relayが提供してくれるので、こちら側で追加のアクションをする必要はありません。

コードが少なくて済むというメリット以外にも、自分で書かなければならないコードが少なくなる、つまり何かをミスする可能性が少なくて済むというメリットもあります。

それでは上のコードの中で、それを可能にしているものを分解してみましょう。難しいものがいくつかありますね。

import { FriendsList_user$key } from './__generated__/FriendsList_user_graphql';
import { FriendsListPaginationQuery } from './__generated__/FriendsListPaginationQuery_graphql';

このコードでは、__generated__フォルダから型定義をインポートしています。これらは、定義したfragmentと、Relayが自動的に生成したページネーションのためのクエリの、両方の型安全を確保するためのものです。

import { getConnectionNodes } from './utils/getConnectionNodes';

getConnectionNodesという関数もインポートします。これはカスタムヘルパーで、任意のconnectionから内部にあるすべてのnodeを型安全な方法で配列に取り出すことができます。公式のRelayのパッケージにはありませんが自分で作るのはとても簡単で、ここで例を見ることができます。標準化されているからこそ簡単に作れるツールの良い例です。

  const { data, hasNext, loadNext, isLoadingNext } = usePaginationFragment<FriendsListPaginationQuery, _>(
    graphql`
      fragment FriendsList_user on User
        @argumentDefinitions(first: { type: "Int!", defaultValue: 5 }, after: { type: "String" })
        @refetchable(queryName: "FriendsListPaginationQuery") {
        friends(first: $first, after: $after) @connection(key: "FriendsList_user_friends") {
          edges {
            node {
              id
              firstName
            }
          }
        }
      }
    `,
    user,
  );

usePaginationFragmentというhookを使って、propsのページネーションに関連する一部を返してくれます。またdataも返していますが、これは定義した FriendsList_userfragmentのデータです。

fragmentといえば、良いことが起きています。fragmentの定義で何が起こっているのか、もっと深く掘り下げてみましょう。

@argumentDefinitions(first: { type: "Int!", defaultValue: 5 }, after: { type: "String" })

Relayではfragmentの引数を定義することができる

まず目立っているのは、fragmentに@argumentDefinitionsというdirectiveを追加したことです。このdirectiveはfirst（Int!型）とafter（String型）という2つの引数を取ります。firstは必須なので、fragmentの引数に値を指定しない場合Relayは定義されているデフォルト値（この場合5）を使用します。

fragmentの引数を定義できることも、モジュール性とスケーラビリティに大きな違いをもたらすRelayの機能の1つです。これがどのように機能するのかについてここでは詳しく説明しませんが、FriendsList_userfragmentを使用しているユーザーは、そのfragmentを使用する際にfirstとafterの値をオーバーライドすることができるようになります。以下のようになります。

query SomeUserQuery {
  loggedInUser {
    ...FriendsList_user @arguments(first: 10)
  }
}

これにより、デフォルトの最初の5人のフォロワーではなく、最初の10人のフォロワーを直接<FriendsList />に取得することができます。

Relayがページネーションqueryを作成する

@refetchable(queryName: "FriendsListPaginationQuery")

先ほどのコードの後には、@refetchableという別のdirectiveがあります。これは、新しい変数でfragmentのデータを再取得できるようにしたいということをRelayに伝えています。directiveに与えられたqueryNameは、生成されるqueryを呼び出すための名前にFriendsListPaginationQueryを使用することを示しています。

これにより、おおむね次のようなqueryが生成されます。

query FriendsListPaginationQuery($id: ID!, $first: Int!, $after: String!) {
  node(id: $id) {
    ... on User {
      friends(first: $first, after: $after) {
        pageInfo {
          endCursor
          hasNextPage
          startCursor
          hasPreviousPage
        }
        edges {
          node {
            id
            firstName
          }
          cursor
        }
      }
    }
  }
}

しかし、このqueryについて知ったり、考えたり、気にする必要はありません！ queryに必要な変数（idやafter、次へページネーションするためのカーソルなど）の供給など、すべての繋ぎ込みはRelayがやってくれます。あなたは取得したいアイテムの数を指定するだけです。

これこそが、Relayによるページネーションをとても人間工学的にしている部分です。Relayが文字通りあなたのためにコードとqueryを記述してくれるので、ページネーションの複雑さをすべて隠してくれます！

ConnectionをRelayに知らせれば、あとはRelayにおまかせ

        friends(first: $first, after: $after) @connection(key: "FriendsList_user_friends") {
          edges {
            node {
              id
              firstName
            }
          }
        }

**friends(first: $first, after: $after)** ここでフィールドを指定します。friendsはページネーションしたいconnectionを持つフィールドです。argumentDefinitionsで定義されているfirstとafterを渡していることに注意してください。

**@connection** friendsには@connection(key: "FriendsList_user_friends") というdirectiveが付いています。このdirectiveは、ページネーションしたいconnectionの場所をRelayに伝えます。このdirectiveを追加することで、サーバに送信されるqueryの中で、connectionを指定した部分にpageInfoの全てのフィールドの指定を自動的に追加するなど、Relay はいくつかのことを行うことができるようになります。これによりRelayはその情報を利用してさらにロードできるかどうかを判断したり、適切なカーソルを自動的に使用してページネーションを行うことができます。このように間違ったことをしてしまう可能性のある手動のステップを削除し、自動化しているのです。

繰り返しになりますが、Relayがこれら全てを行ってくれるのであなたが何かを見たり考える必要はないものの、サーバーに送信されるfriendsの指定は次のようになります。

friends(first: $first, after: $after) {
  pageInfo {
    endCursor
    hasNextPage
    startCursor
    hasPreviousPage
  }
  egdes {
    node {
      ...
    }
    cursor
  }
}

@connectionアノテーションを追加することで、Relayはページネーションに必要な項目を追加するべき場所を知ることができます。

さらに@connectionが行うのは、キャッシュの更新でアイテムを追加したり削除したりするときなど、キャッシュ内でこのconnectionと対話する必要がある場合³に使用するキーをRelayに指定することです。複数のリストで同じconnectionを介してページネーションする場合があるため、ここで一意のキーを設定することは重要です。

これはまた、Relayがページネーションのレスポンスから取り出して現在のページネーションリストに追加する必要のある、すべての場所を推測できることを意味します。

        <button disabled={isLoadingNext} onClick={() => loadNext(5)}>

それ以外、Relayが提供するものを実際に使用するコードのほとんどはかなり自明のはずです。

これはどのように機能するのか？

つまり、ページネーションがどのように見えるかをまとめると、基本的にはfragmentの定義の中でdirectiveを使って必要な情報をRelayに渡し、その見返りとしてRelayができる限りのことを自動化してくれるということになります。

しかし、このようなことをRelayはどのようにして実現できるのでしょうか？

それはすべて規則と標準化に帰着します。グローバルな識別とnodeインターフェースの仕様に従えば、Relayは以下のことが可能です。

現在いる特定のnodeを再取得するためのqueryを自動的に生成し、そのqueryに再取得中のfragmentを自動的に追加します。
対象となるオブジェクトのidが特定のオブジェクトのみを示すことが分かっているため、生成されたクエリに変数を与える必要がないことを保証します²。

また、Connectionのページネーション仕様に従うことで、Relayは以下のようなことができます。

初期queryとなるProfileQueryと生成されたFriendsListPaginationQueryのqueryの両方に、必要なメタデータの指定を自動的に追加します。
データの構造が標準化されたconnectionであることを知っているので、ページネーションの結果を既存のリストに自動的にマージします。したがって、必要なものは全て取り出せます。
標準化された方法でpageInfoで利用できるようになるため、より多くの結果をロードするために使用するカーソルを自動的に追跡します。pageInfoは、（上で述べたように）あなたが知らないところで自動的にクエリに挿入することができます。これも標準化されているからできることです。

そして、その結果は本当に素晴らしいものになっています。Relayは、ページネーションを人間工学的にしただけでなく、手作業でのエラーが発生する可能性をほぼすべて排除してくれました。

まとめ

この記事では、Relayのようなフレームワークがどれだけ自動化できるのか、また、規則に従えばDXがどれだけ素晴らしいものになるのか、ということにスポットを当ててみました。この記事では、以下の内容に光を当てました。

GraphQLでのページネーションは多くの手作業を必要とし、開発者をミスさせてしまう可能性があります。
規則に従うことで、Relayのようなフレームワークはページネーションの開発体験を信じられないほど人間工学的なものに変えることができ、手作業によるエラーの原因となることのほとんど（すべてではないにしても）を取り除くことができます。

これは良い入門編ですが、Relayにはページネーションのための機能が他にもたくさんあります。詳細についてはRelayの公式ドキュメントをご覧ください。

最後までお読みいただきありがとうございました！

訳注：$userLoginのこと。ProfileQueryとUserProfileFollowersPaginationQueryの両方に同じ値を指定する必要があります。
↩
訳注：自動的に生成されたクエリに対して何らかの変数を与える必要はないということです。最初にqueryでアクセスできたオブジェクトのidを使用して、そのオブジェクト配下のリストを取得するqueryを実行できるので、複雑な変数は不要です。仮にidが一意ではなかったりnodeインターフェースがない場合、リストを所有するオブジェクトを単一で取得するqueryを自動生成する方法がありません。
↩
訳注：対話する必要がある理由は、アイテムを追加したり削除するなら、connectionからも同様に追加したり削除する必要があるからです。そうしないとリストのコンポーネントはユーザーのアクション（追加や削除）で変化しません。
↩

GraphQLでのConnectionベースのページネーション

Thu, 27 Aug 2020 15:00:00 GMT

GraphQLではConnectionベースのページネーションが一般的だ思いますが、一度は「なんでこんな仕様なんだ、もっとシンプルにできるだろ」と思うものですよね。この翻訳記事ではConnectionベースのページネーションについて深く掘り下げ、なぜこうする必要があるのか、どのようなメリットが得られるかを解説します。

（原文）

Relay入門シリーズ（全4記事）
Relay：あなたのために泥臭い仕事をしてくれるGraphQLクライアント
GraphQLでのConnectionベースのページネーション（本記事）
Relayを使って最小限の努力でページネーションをする
Nodeインターフェースの魔法

この連載は、Gabriel NordebornとSean Groveが執筆しています。GabrielはスウェーデンのITコンサルタント会社Arizonのフロントエンド開発者でありパートナーでもあり、長い間Relayを利用してきました。SeanはサードパーティのAPIをGraphQLで統一するOneGraph.comの共同創業者です。

Connectionベースのページネーションはどのようにページネーションするかを構造化する方法で、シンプルなページネーションから少し高度なページネーションまで対応しています。このページネーションの方法は最近GraphQLの公式のベストプラクティスに昇格しました。この記事では、なぜこれがGraphQLでは良いことなのか、また、どのようなタイプのツールが使えるようになるのかに焦点を当ててみたいと思います。

Connectionベースのページネーションとは何か、なぜそれが有用なのかについては、多くのリソースがあります。この記事を読む前に、まずはGraphQLの公式サイトのページネーションのセクションを見てみることをお勧めします。

標準化が勝利をもたらす

Connectionベースのページネーションは、ページネーションのために標準化された取り決めを使用するということです。なぜそんなことを気にするのでしょうか？この記事でお見せするように、標準化された取り決めを使うことはツールやフレームワークをページネーションと深く統合できることを意味します。そしてそれは、あなたの開発者としての人生がずっと楽になることを意味します。また、ツールがヘビーな仕事をしてくれるので、より早くリリースできるということも意味します。

それは何で、何に適しているのか？

Connectionベースのページネーションは、既存のリストに任意の量のアイテムを追加し続けるようなUI、つまり無限スクロール型のページネーションに最適です。既存のリストにアイテムを追加し続けるのではなく、ページ全体のアイテムを個別に取得するページネーション¹を実装したい場合は、別で実装した方が良いでしょう。

ここで重要なのは、Connectionベースのページネーションは、ページネーションのための取り決めを構造化する方法にすぎないということです。Connectionベースのページネーションを使用する場合、バックエンドでデータを取得する方法に影響があるかもしれませんが、GraphQLの世界でこれを使用する主な目的は、バックエンドを特定のページネーション戦略にコミットさせずに、ページネーションのための標準化された構造を提供することです。

ページネーションのための標準化された構造

それでは、Connectionベースのページネーションの構造の例を見てみましょう。あなたが好きだと思う映画を見つけるための検索機能を構築していると想像してみてください。私たちのバックエンドの検索エンジンは非常にスマートなので、あなたが見たいと思うものを評価する際に、さまざまな要素を考慮することができます。以下の定義は、任意の検索ワードでMovieのリストを取得し、ページネーションすることを表現しています。検索ワードは、アクション映画、または恋愛コメディのようなものである可能性があります。私たちの検索エンジンは、それをすべて理解できます！

気軽に下記の仕様に目を通してみてください。今は理解しようしなくて大丈夫です。記事を読み進める上で、大体の形が頭に入っていれば良いと思います。

type Movie {
  id: ID!
  name: String!
  releasedYear: Int!
  coverUrl: String!
}

# Movie型のedge
type MovieEdge {
  node: Movie # node。このEdgeの中ではMovieです
  cursor: String # このEdgeのカーソル
}

# 現在のページネーションのメタデータ
type PageInfo {
  hasNextPage: Boolean!
  endCursor: String
  hasPreviousPage: Boolean!
  startCursor: String
}

# connection。ページネーションのrootの型です
type MovieConnection {
  pageInfo: PageInfo!
  edges: [MovieEdge]
}

type Query {
  # first、last、after、beforeを使ってページを前後させることができます
  movies(
    query: String!
    first: Int, 
    last: Int, 
    after: String, 
    before: String
  ): MovieConnection
}

本当に簡単なはずのものにしては構造が多いですよね？上記の構造を頭に入れておいて、ページネーションがどのように実装され、またプロジェクトでどのように成長するのか、典型的なシナリオを見てみましょう。

ページネーションの実装方法の一般的なシナリオ

ほとんどのアプリケーションでは、遅かれ早かれ何らかの形でのページネーションが必要となり、様々な方法で実装することができます。ここでは最も一般的でありきたりなページネーションをGraphQLで実装するとどのようになるか、シナリオを描いてみましょう。

Step 1. 可能な限りシンプルなページネーション

先ほどの映画の例をもとに、西部劇や激しいアクションなど、任意の検索クエリで映画をページネートできる検索機能を設計します。

ほとんどの人は（当然ですが）基本的なことから始めます。つまり、「非常にシンプルなページネーションをしたいだけで、派手なことをする必要はない」ということです。通常は次のようになります。

type Query {
  searchMovies(
    query: String!
    limit: Int
    offset: Int
  ): [Movie!]
}

私たちは、検索クエリを使用してMovieの単純なリストをフィルタリングし、その検索クエリに最適にマッチする映画を見つけます。これはすべて問題なく、うまく機能しています。

Step 2. さらに検索結果があるかを知るにはどうすれば良いのか？

製品は進化していくので、取得できる映画が増えた場合にはUIに「もっと見る」ボタンを追加したいと思います。しかし、上の例ではリストを返しているだけなので、さらにロードするべき検索結果があるかどうかを知る方法がありません。

これも簡単に解決できますね！例を拡張してみましょう。個々のMovieを変更したくないので（そこにhasNextPageプロパティを持っていても意味がないでしょう²）、searchMoviesがメタデータを置くことができる小さなラッパーオブジェクト（MovieSearchResult）を返す必要があります。

type MovieSearchResult {
  hasNext: Boolean
  items: [Movie!]
}

type Query {
  searchMovies(
    query: String!
    limit: Int
     offset: Int
  ): MovieSearchResult!
}

素晴らしい。これで必要なものは全て揃いましたね。問題は解決しました。

Step 3. オフセットを使用する場合

製品はさらに進化し、私たちは今、検索結果の中に含まれる特定のMovieからページネーションを継続できる一意のURLを生成する必要があります。

パッと思いつくやり方としては、次のようなURLを構築することかもしれません。 /search?limit=${limit}&offset=${offset}&query=${query} これでいいんじゃないでしょうか？悲しいことに、そうではありません。

私たちがこの検索結果からある映画を見ているとして、その検索結果のリストの前に加えられるような映画をデータベースに追加した場合どうなるのでしょうか？オフセットは目的の映画を指し示すことはありません。

一歩引いて考えてみましょう。人間がバックエンドAPIのメンテナと話しているように、私たちの意図を表現してみます。

私は「Frost 2」までの映画の検索結果をすべて持っています。「Frost 2」の次の10作品をお願いします。

私たちは人間でも分かるように意図を十分説明し、「ああ、あなたの検索クエリにマッチする結果にはいくつかの映画が追加されたり削除されたりしましたが、ここではFrost 2以降の10作品を表示しますね」と言われました。これがページネーションに求める動作です！

これを機能させるには、検索結果の特定のアイテムからページネーションできるようにする必要があります。そのため、当然のことながら結果の中の1つのアイテムを識別する方法が必要になります。ここに”カーソル”（cursor）と呼ばれる、そのための既存の概念があります。我々はまさにその概念を使用し（一流の芸術家は盗む、そういうことです）、そしてそれをサポートするために私たちの検索クエリを微調整します。

type MovieSearchResultWrapper {
  movie: Movie
  cursor: String
}

type MovieSearchResult {
  hasNext: Boolean
  items: [MovieSearchResultWrapper!]
}

type Query {
  searchMovies(
    query: String!
    limit: Int
    cursor: String
  ): MovieSearchResult!
}

これでoffsetではなくcursorで映画を検索できるようなり、結果ごとにcursorでアクセスできるようになります。これにより、ページネーションが安定します（現在のアイテムの前に追加されたアイテムは、以前のようにリストを混乱させることはありません）。これで次のようなURLを生成することができます。

/search?limit=${limit}&cursor=${cursor}&query=${query}

このURLは安定⁵しており、常に検索結果リストのアイテムから始まる検索結果を指すようになります（たとえその間にいくつかのアイテムが追加されたり削除されたりしていても）。素晴らしいですね！

Step 4. 検索結果の個々のアイテムに関連するメタデータ

新しい機能のリクエストが入ってきました。検索結果がどれだけあなたの好みにマッチしているか、また検索クエリにどれだけ関連性があるか、ということについて知っているため、当然ながらそれをユーザーに表示したいと考えています。

一方で、これは特定の検索クエリに対する特定の検索結果のアイテムに対してのみ有効なデータです。私たちの検索エンジンは、検索結果に対して効率的な方法でその情報を自動的に生成してくれます（結果の順序付けに既に使用している情報なので）。しかし、ルートのMovie型を拡張したくない場合（この拡張は本当に筋が悪いので³）、それぞれの結果の情報を置ける場所は論理的にどこでしょうか？さて、カーソルのニーズのために先ほどMovieSearchResultWrapperを導入したところですが、これは特定の検索に関連するメタデータだけを保持しますね。そこに置いてみましょう。

type MovieSearchResultWrapper {
  movie: Movie
  cursor: String
  relevanceFactor: Float
}

素晴らしい！これで素敵な数字を手に入れたので、派手なゲージメーターに変えることができ、みんながハッピーになることでしょう。

待てよ、Connectionベースのページネーションを自然と実装しただけでは？

ここで自然と作ってきたものを見て、Connectionベースのページネーションで作成した最初の構造と比較すると、この2つは事実上同じではないでしょうか？その通りです！上記のモデルをConnection構造に当てはめてみましょう。

type Movie {
  id: ID!
  name: String!
  releasedYear: Int!
  coverUrl: String!
}

type MovieEdge {
  node: Movie # "node"はコレクション内のアイテムの一般的な名前です
  cursor: String # 検索結果のアイテムのカーソルはここに自然に収まります
  relevanceFactor: Float # この検索結果にのみ関連する追加のメタデータもここに収まります
}

# ページネーションをするために必要な全てのメタデータ
type PageInfo {
  hasNextPage: Boolean!
  endCursor: String
  hasPreviousPage: Boolean!
  startCursor: String
}

# ページネーションのルート型。繰り返しますが、一般化/標準化された名前です
type MovieConnection {
  pageInfo: PageInfo!
  edges: [MovieEdge]
}

type Query {
  searchMovies(
    query: String!
    first: Int, 
    last: Int, 
    after: String, 
    before: String
  ): MovieConnection
}

そういうことなので、独自の命名法を使う代わりにページネーションをConnectionベースのモデルに簡単に適合させることができます。しかし、そんなことをして何のメリットがあるのでしょうか？もしかしたら、あなたはこの命名に反対しているのかもしれませんし、複雑すぎると思っているのかもしれませんし、当面はシンプルなページネーションだけが必要な段階にあるのかもしれません。なぜ気にするのでしょうか？

テンプレは意思決定をなくし、ときめき⁴をもらたす他のものに集中することができる

上記のスキーマを使用してテンプレート化できるようになったので、私たちは何か（好きな名詞を入れてください）のリストをページネートしたい時には、穴埋めを行うだけでできるようになりました。

# nounには好きな名詞を入れてください
type ${noun} {
  ${...フィールドを書く}
}

type ${noun}Edge {
  node: ${noun} # "node"はコレクション内のアイテムの一般的な名前です。つまりnounです。
  cursor: String # 検索結果のアイテムのカーソルはここに自然に収まります
  ${...nounのためのページネーションの他のメタデータ}
}

# ページネーションをするために必要な全てのメタデータ
# ここは同じままです！
type PageInfo {
  hasNextPage: Boolean!
  endCursor: String
  hasPreviousPage: Boolean!
  startCursor: String
}

# ページネーションのルート型。繰り返しますが、一般化/標準化された名前です
type ${noun}Connection {
  pageInfo: PageInfo!
  edges: [${noun}Edge]
}

type Query {
  ${noun}s(
    query: String!
    first: Int, 
    last: Int, 
    after: String, 
    before: String
  ): ${noun}Connection
}

このようなテンプレートを持つことで、${noun}のリストのページネーションを簡単に作ることができます。

標準化 == ツールを使うことで人生が楽になる

もっと重要なのは、私たちが今まで築き上げてきたこれらの慣習が、私たちの開発者としての人生をシンプルにするためのツールの構築を簡単にしてくれるということです。ここでは、Connectionベースのページネーションがもたらすいくつかの利点と、ツールがあなたのためにできることをご紹介します。

未来を保証するページネーション Connectionベースのページネーションのために提供される構造は、ページネーションの際に必要になるかもしれないもの（カーソル、追加の結果に関するメタデータ、特定の検索におけるこの特定の結果アイテムに関するメタデータなど）を論理的に配置する場所を提供してくれるため、Connectionベースのページネーションを実装する際にAPIの将来性を保証することができます。最初に説明したような高度な機能を必要としない場合でも、構造がすでにあるため必要になったときに追加するのは簡単です。

一般化されたツール 一般化されたツールを書くことが簡単になります。例えば、任意の${noun}Connectionを受け取り、そのConnectionのノードのリストを返す関数などです。これにより、やや複雑なConnectionの構造を手動で扱う必要がなくなります。

また、バックエンドでツールを構築するのも簡単です。先と同じことが当てはまり、標準化されているため汎用的なツールを構築することができます。例えば、上で見たテンプレートを1つのmakeNounPaginator(...)という関数にすることができるので、バックエンドでページネーションを作るのも簡単です！

フレームワークにすべての作業を任せる しかし、フロントエンド開発者としては、標準化されていれば、フレームワークがその上に構築できるというのが一番の利点かもしれません。Relayはその素晴らしい例です。Relay のページネーションは、Connectionの仕様に従えば信じられないほど人間工学的で簡単です。Relayのページネーションとその優れた点について説明した記事をご紹介しますので、ぜひ読んでみてください。

まとめ

この記事を読むことで、Connectionベースのページネーションとは何か、そしてなぜそれが意味をなすのかについての感覚が得られたことを願っています。

また、上述したように、Relayでのページネーションに関する記事もぜひ読んでみてください。Relayはここで紹介した内容を活用して、ページネーションを行うための優れた開発者エクスペリエンスを実現しています。これはConnectionベースのページネーションのような標準化された構造が可能にする、まさに良い典型例です。

もしあなたがEggheadの会員で、この記事を 11 分間のビデオ形式でご覧になりたい方は、Nik Graf のPaginate Entries using the Connection Specification lessonをご覧ください！

訳注：ページ番号がついているようなUIのページネーションです。工夫が必要ですが、Connectionベースのページネーションを使っても実装できます例） https://artsy.github.io/blog/2020/01/21/graphql-relay-windowed-pagination/
↩
訳注：例えば10個ずつ映画を取得するとして、1個目や2個目のMovieにhasNextPageがあっても使いようがありません。10件の結果結果自体に次のページがあるかどうかを示すフィールドが存在するべきです。
↩
訳注：ここで付与したいのは検索の文脈でのみ使われる情報であり、Movie自体が持つ情報ではありません。仮にMovieを拡張すると、Movieを1つ取得する場合などでこのフィールドにどう結果を入れれば良いか分からなくなります。これが「これは特定の検索クエリに対する特定の検索結果のアイテムに対してのみ有効なデータ」ということです。
↩
訳注：原文はsparks joy(tm)。こんまりメソッドのときめきのことね。 https://www.youtube.com/watch?v=c8eYPDmpyd4
↩
訳注：現実世界では、このような安定的なリストを生成するためにはバックエンドで工夫が必要です。バックエンドで使うGraphQLフレームワークの多くは、DBに問い合わせる時のoffsetをカーソルに変換しているため安定性を備えていません。標準的な実装であるgraphql-relay-jsもそうなっており、もちろん「offsetに依存しているためにリストに変更がない場合しか動作しない」と明記されています https://github.com/graphql/graphql-relay-js/blob/8f4ed1ad35805ef233ad9fd1af33abb9c0cad35a/src/connection/arrayconnection.js#L17-L19 安定的なリストを作成するためにはidなどを使ってカーソルを生成する必要があります（ソートを行いながら）。ここでは詳細に記述しませんが、実装はかなり難しくなり、速度も低下する可能性があります。
↩

Relay : あなたのために泥臭い仕事をしてくれるGraphQLクライアント

Wed, 26 Aug 2020 15:00:00 GMT

私はGraphQLクライアントのRelayのファンで、2年ほど前から使用しています。 Relayは現代のフロントエンドの開発抱える課題とGraphQLへの深い理解に裏打ちされたFacebook渾身のフレームワークですが、残念ながらその哲学は十分に理解されていなかったように思います。

そして2020年。ついにRelayをうまく表現した文章がやってきました。本記事はその翻訳になります ¹。普段は異なるGraphQLクライアントを使っている方でも、Relayの哲学はコンポーネント指向のフロントエンド開発者なら刺激的で参考になると思います。ぜひご覧ください。

（原文）

Relay入門シリーズ（全4記事）
Relay : あなたのために泥臭い仕事をしてくれるGraphQLクライアント（本記事）
GraphQLでのConnectionベースのページネーション
Relayを使って最小限の努力でページネーションをする
Nodeインターフェースの魔法

この連載は、Gabriel NordebornとSean Groveが執筆しています。GabrielはスウェーデンのITコンサルタント会社Arizonのフロントエンド開発者でありパートナーでもあり、長い間Relayを利用してきました。SeanはサードパーティのAPIをGraphQLで統一するOneGraph.comの共同創業者です。

この連載では、ひとつの疑問に明確に答えるために、Relayを深く掘り下げていきたいと思います。

「Relay（Facebookが提供するGraphQLを使ったアプリケーションを構築するためのJavaScriptクライアントフレームワーク）になぜ私が興味を持つのか？」

これは良い疑問です。その疑問に答えるために、ブログをレンダリングする簡単なページを構築するところから見ていきましょう。ページを構築していくと、2つの主要なテーマが浮かび上がってきます。

Relayは実際、あなたのために望んで泥臭い仕事をする働きものです
Relayが提示する規則に従えば、GraphQLを使ってクライアントサイドのアプリケーションを構築する際に素晴らしい開発者体験を提供してくれます

また、Relayを使ったアプリケーションがスケーラブルで、パフォーマンスが高く、モジュール化されており、何もせずともデフォルトで変更に強く、そしては現在開発中のReactの新機能に対応した将来性のあるものになることもお見せします。

Relayには（若干の）コストがかかりますが、これについては正直に前もって検討しますので、トレードオフについては十分に理解していただけます。

この記事について

この記事ではRelayの考え方や哲学を紹介することを目的としています。時折、他の GraphQLフレームワークとRelayの動作を比較することはありますが、この記事は Relayと他のフレームワークを比較すること自体を目的にしていません。Relayの哲学やアプリケーション構築に関わる概念を説明し、Relayそのものについて深く掘り下げていきたいと考えています。

この記事に掲載しているコードサンプル（いくつかあります！）は、あくまでもRelayの動作を説明するためのものであり、少し浅く単純化されているかもしれません。

また、ReactのSuspenseとConcurrent Modeに完全対応した、Relayの新しいHooksベースのAPIにも注目します。新しいAPIはまだexperimental ²ですが、FacebookはRelayとデータレイヤー専用のAPIを使ってfacebook.comを再構築しています ³。

始める前に、この記事ではGraphQLの基本的な知識とクライアントサイドのJavaScriptアプリケーションの構築について基本的な知識があることを前提としています。GraphQLについては、まだよくわかっていないという方はこちらの記事で紹介しています。コードサンプルはTypeScriptで書かれているので、Typescriptの基本的な理解があればそれも役立つでしょう。

最後に、この記事はかなり長いです。何度も読み返すことができる参考記事として参照してください。

ここまでの点をふまえて、さっそく始めましょう!

Relayの概要

Relayは、GraphQLコードを最適化するコンパイラと、Reactで使用するライブラリで構成されています。

深く飛び込む前に、まずはRelayの概要を簡単に説明しましょう。Relayは2つの部分に分けることができます。

コンパイラ：あらゆる種類の最適化、型の生成、そして優れた開発者体験を可能にする役割を担っています。Relayを使って開発している時はコンパイラはバックグラウンドで動作します。
ライブラリ：Relayのコアと、ReactでRelayを使用するためのバインディング。

この時点でコンパイラについて知っておくべきことは、あなたが起動する別プロセスですべてのGraphQLのoperation ⁴を監視してコンパイルするということだけです。コンパイラの詳細についてはすぐに説明します。

加えて、Relayが最適に動作するためには、スキーマが3つの規則に従うことが必要です。

GraphQLの型のすべてのidフィールドはグローバルに一意であること（つまり、異なる種類のオブジェクトであっても、2つのオブジェクトは同じidの値を持ってはいけません）。
Nodeインターフェースが必要です。これが意味するのは、グラフ内のオブジェクトはトップレベルのnodeフィールドでidフィールドを指定して取得できるべきということです。グローバルに一意なidとNodeインターフェースについての詳細は、こちらの記事を参照してください。
ページネーションは、コネクションベースのページネーション規則に従うべきです。コネクションベースのページネーションとは何か、なぜそれが良いアイデアなのかについては、こちらの記事を読んでください。

この時点では規則についてはこれ以上深く掘り下げませんが、興味のある方は上記のリンク先の記事をチェックすることをお勧めします。

Relayの核心: fragment

まず最初に、RelayとGraphQLの統合の核となるコンセプトについてお話しましょう。それがfragmentです。fragmentは、Relay（とGraphQL！）の力を発揮するための主要なキーの一つです。

簡単に言えば、GraphQLのfragmentとは、特定のGraphQLの型（type）で共通の項目をグループ化する方法のことです。以下に例を示します。

fragment Avatar_user on User {
  avatarUrl
  firstName
  lastName
}

興味のある方のために: fragmentの名前に Avatar_user という名前を付けることは、Relayが強制している規則です。Relayでは、すべてのfragmentの名前はグローバルに一意で、<moduleName>_<propertyName>の構造に従うようにします。fragmentの命名規則についてはこちらをご覧ください。

これはGraphQLの型であるUserで使用できるAvatar_userという名前のfragmentを定義しています。このfragmentはアバターをレンダリングするのに必要なフィールドを指定します。このfragmentを使うことで、アバターのレンダリングに必要なフィールドを必要な場所ごとで明示的に指定するのではなく、query全体でこのfragmentを再利用することができます。

# authorのアバターとlikedByで使用するアバーターで別々に定義する代わりに…
query BlogPostQuery($blogPostId: ID!) {
  blogPostById(id: $blogPostId) {
    author {
      firstName
      lastName
      avatarUrl
    }
    likedBy(first: 2) {
      edges {
        node {
          firstName
          lastName
          avatarUrl
        }
      }
    }
  }
}

# こうやってAvatar_userでまとめることができる
query BlogPostQuery($blogPostId: ID!) {
  blogPostById(id: $blogPostId) {
    author {
      ...Avatar_user
    }
    likedBy(first: 2) {
      edges {
        node {
          ...Avatar_user
        }
      }
    }
  }
}

こうすると定義を再利用できるので便利ですが、より重要なのは、アプリケーションの進化に合わせてアバターをレンダリングするのに必要なフィールドを一箇所で追加したり削除したりできることです。

fragmentを使用すると、GraphQL 型のフィールドの再利用可能な指定を定義することができます。

Relayはfragmentをもっと推し進める

GraphQLクライアントアプリケーションを長期的にスケールさせするためには、データをレンダリングするコンポーネントを必要なデータと一緒に配置する（コロケーション）ことが良い方法です。そうすることで、コンポーネントのメンテナンスや拡張が非常に簡単になります。

fragmentでは（上記で説明したように）特定のGraphQLの型のフィールドのサブフィールド ⁵を定義することができるので、コロケーションの考え方にぴったりです。

コンポーネントではレンダリングする必要のあるデータを記述した1つ以上のfragmentを定義するのが良い方法です。これは、コンポーネントが「親コンポーネントが誰であるかに関係なく、User型のこれら3つのフィールドに依存している」と言うことができることを意味します。上の例では、<Avatar />という名前のコンポーネントがあり、Avatar_user fragmentで定義されたフィールドを使ってアバターを表示します。

ほとんどのフレームワークでは、何らかの方法で GraphQL fragmentを使用することができます。しかし、Relayはこれをさらに進化させています。Relayでは、ほとんどすべてがfragmentを中心に展開されています。

RelayはどうやってGraphQL fragmentを展開するのか

根本的に、Relayはすべてのコンポーネントに対して、コンポーネントと共に全てのデータの要件を完全かつ明示的にリストアップさせたいと考えています。これによりRelayはfragmentと深く統合することが可能になります。これが何を意味し、何を可能にするのかを分解してみましょう。

コロケーションされたデータ要件とモジュール性

Relayでは、fragmentを使用してコンポーネントのデータ要件を実際に使用しているコードのすぐそばに配置します。Relayの規則に従うことで、すべてのコンポーネントがアクセスを必要とするすべてのフィールドを明示的にリストアップすることが保証されます。つまり、明示的に要求されていないデータに依存するコンポーネントは存在しないということです。コンポーネントはモジュール化されており、自己完結型であり、再利用やリファクタリングに強くなります。

Relayでは、fragmentを使ってモジュール化を可能にするためのさまざまな機能も提供していますが、それについてはこの記事の後半で少し触れます。

パフォーマンス

Relayでは、コンポーネントは使用しているフィールドが変更された場合にのみ再レンダリングを行います。あなたが何かをする必要はありません！これは各fragmentが指定したデータの更新のみを受け取るためです。

Relayはデフォルトでビューの更新方法を最適化しているため、アプリの成長に伴ってパフォーマンスが不必要に低下することはありません。これは他のGraphQLクライアントの動作とは全く異なります。以下では、これがスケーラビリティにとってどれほど重要であるかについて、いくつかの素晴らしい例を紹介します。

以上のことを念頭に置いて、いよいよページの構築に取り掛かりましょう

Relayはfragmentの概念を推し進め、データ要件のコロケーション、モジュール性、優れたパフォーマンスを可能にするために利用しています。

ブログ記事をレンダリングするページの構築

これは、1つのブログ記事を表示するページがどのように見えるかを説明したワイヤーフレームです。まず、このビューのすべてのデータを1つのトップレベルのqueryで取得する方法を考えてみましょう。ワイヤーフレームのニーズを満たすための合理的なqueryは、次のようになります。

query BlogPostQuery($blogPostId: ID!) {
  blogPostById(id: $blogPostId) {
    author {
      firstName
      lastName
      avatarUrl
      shortBio
    }
    title
    coverImgUrl
    createdAt
    tags {
      slug
      shortName
    }
    body
    likedByMe
    likedBy(first: 2) {
      totalCount
      edges {
        node {
          firstName
          lastName
          avatarUrl
        }
      }
    }
  }
}

1つのqueryで必要なデータをすべて取得することができます！良いですね！

そして、UIコンポーネントの構造は以下のようになるかもしれません。

<BlogPost>
  <BlogPostHeader>
    <BlogPostAuthor>
      <Avatar />
    </BlogPostAuthor>
  </BlogPostHeader>
  <BlogPostBody>
    <BlogPostTitle />
    <BlogPostMeta>
      <CreatedAtDisplayer />
      <TagsDisplayer />
    </BlogPostMeta>
    <BlogPostContent />
    <LikeButton>
      <LikedByDisplayer />
    </LikeButton>
  </BlogPostBody>
</BlogPost>

これをRelayで構築する方法を見てみましょう。

Relayでのデータの問い合わせ

Relayでは、ブログ記事をレンダリングするルートコンポーネントは通常以下のように書きます。

// BlogPost.ts
import * as React from 'react';
import { useLazyLoadQuery } from 'react-relay/hooks';
import { graphql } from 'react-relay';
import { BlogPostQuery } from './__generated__/BlogPostQuery.graphql';
import { BlogPostHeader } from './BlogPostHeader';
import { BlogPostBody } from './BlogPostBody';

interface Props {
  blogPostId: string;
}

export const BlogPost = ({ blogPostId }: Props) => {
  const { blogPostById } = useLazyLoadQuery<BlogPostQuery>(
    graphql`
      query BlogPostQuery($blogPostId: ID!) {
        blogPostById(id: $blogPostId) {
          ...BlogPostHeader_blogPost
          ...BlogPostBody_blogPost
        }
      }
    `,
    {
      variables: { blogPostId },
    },
  );

  if (!blogPostById) {
    return null;
  }

  return (
    <div>
      <BlogPostHeader blogPost={blogPostById} />
      <BlogPostBody blogPost={blogPostById} />
    </div>
  );
};

ここで何が起こっているのか、一歩一歩分解してみましょう。

const { blogPostById } = useLazyLoadQuery<BlogPostQuery>(
    graphql`
      query BlogPostQuery($blogPostId: ID!) {
        blogPostById(id: $blogPostId) {
          ...BlogPostHeader_blogPost
          ...BlogPostBody_blogPost
        }
      }
    `,
    {
      variables: { blogPostId },
    },
  );

まず注意したいのは、次のようにReactのhookであるuseLazyLoadQueryをRelayから利用することです。 const { blogPostById } = useLazyLoadQuery<BlogPostQuery> useLazyLoadQueryは、コンポーネントがレンダリングされるとすぐにBlogPostQueryの取得を開始します。

型の安全性を確保するために、useLazyLoadQueryに型を指定します。./__generated__/BlogPostQuery.graphqlからインポートしたBlogPostQueryという型を明示的に指定しています。このファイルはRelayコンパイラによって自動的に生成され（queryの定義を変更すると同期して保存されます）、queryに必要なすべての型情報（戻ってくるデータがどのように見えるか、queryが必要とする変数は何かなど）を持っています。

留意点！：前述したように、useLazyLoadQueryは、queryがレンダリングされるとすぐにqueryの取得を開始します。しかし、Relayは実際には、このようにレンダリング時にデータを遅延ロードで取得することを望んでいません。むしろ、ページのレンダリングと同時にではなく、ユーザーが新しいページへのリンクをクリックしたときなど、できるだけ早くqueryの読み込みを開始してほしいと考えています。なぜこれが重要なのかについては、こちらのブログ記事やトークで詳しく説明しています。この記事では、ほとんどの人にとってより身近なメンタルモデルであることと、できるだけシンプルで簡単に理解できるようにするために、まだ遅延ロードを使用しています。しかし、前述したようにこれは実際にRelayを使って構築する際にqueryでデータを取得する方法ではないことに注意してください。

次に、実際のqueryを見てみましょう。

    graphql`
      query BlogPostQuery($blogPostId: ID!) {
        blogPostById(id: $blogPostId) {
          ...BlogPostHeader_blogPost
          ...BlogPostBody_blogPost
        }
      }
    `

このqueryにはほとんど解説する部分はありません。queryにはブログ記事をIDで指定する以外に、あと2つの項目があります。BlogPostの<BlogPostHeader />と<BlogPostBody />のfragmentです。

使用しているfragmentをインポートする必要がないことに注意してください。これらはRelayコンパイラによって自動的にインポートされます。これについては後ほど詳しく説明します。

このようにfragmentを組み合わせてqueryを構築することは非常に重要です。別のアプローチとしては、コンポーネントごとに独自のqueryを定義させて、独自にデータを取得する責任を持たせるという方法もあります。これにはいくつかの有効なユースケースがありますが、2つの大きな問題があります。

1つのqueryではなく、大量のqueryがサーバに送られてきます。
queryを作成する各コンポーネントは、実際にレンダリングされてからデータの取得を開始するまで待たなければなりません。つまり、リクエストはウォーターフォールで行われるため、ビューの読み込みが必要以上に遅くなる可能性が高いということです。

Relayでは、コンポーネントを組み合わせてUIを構築します。これらのコンポーネントでは、他のコンポーネントがどのようなデータを必要としているのか見えないように定義します。

Relayでモジュール性をどのように実現するか

上のコードで覚えておくべきメンタルモデルは以下の通りです。

BlogPostコンポーネントは2つの子コンポーネント、BlogPostHeaderとBlogPostBodyをレンダリングしたいことだけを知っています。2つのコンポーネントがどのようなデータを必要としているのかは知りません（親コンポーネントが知る必要はありませんよね。それは子コンポーネントのやるべきことです！）。代わりに、必要なすべてのデータはGraphQLのBlogPost型のBlogPostHeader_blogPostおよびBlogPostBody_blogPostと呼ばれるfragmentに含まれていると子コンポーネントは教えてくれます。これらのfragmentをqueryに含める限り、詳細がわからなくても、必要なデータを確実に取得できることがわかっています。そして、必要なデータを手に入れたら、それらをレンダリングすることができます。

私たちは、独自のデータ要件を定義するコンポーネントを独立して構成することで UI を構築します。これらのコンポーネントは、独自のデータ要件を持つ他のコンポーネントと一緒に構成することができます。しかし、どのコンポーネントも他のコンポーネントがどのようなデータを必要としているかについては、そのコンポーネントがどのGraphQLのデータソース（型）からデータを必要としているか以外は何も知りません。Relayは、泥臭い作業を処理して、適切なコンポーネントが適切なデータを取得するようにしたり、サーバに送信されるqueryで必要なデータが一括ですべて指定さるようにします。

これにより、開発者はコンポーネントとfragmentを独立して考えることができ、Relayが全てを繋ぎ合わせる作業を担当してくれます。

それでは次のステップへ行きましょう！

Relayコンパイラは、あなたのプロジェクトで定義したすべてのGraphQLコードを把握している

先ほどのqueryでは2つのfragmentを参照していましたが、それらのfragmentがどのファイルのどこで定義されているかを指定したり、queryに手動でインポートしたりする必要はありませんでした。これは、Relayでは各fragmentにグローバルに一意な名前を付与しているため、Relayコンパイラはそれらを見つけてサーバに送信するqueryにfragmentの定義を自動的に含めることができるからです。

手作業でfragmentの定義を参照することは、不便で、手動で、エラーが発生しやすい作業ですが、Relayでは開発者の責任ではありません。

コンポーネントと密接に結合されたfragmentを使用することで、Relayはコンポーネントのデータ要件を外部から隠すことができ、モジュール性と安全なリファクタリングが可能になります。

最後に、結果をレンダリングする部分を見てみましょう。

// 両方のフラグメントをblogPostByIdに展開させているので、`BlogPostHeader` と `BlogPostBody` の両方のコンポーネントの要件を満たすことが保証されています。
  if (!blogPostById) {
    return null;
  }

  return (
    <div>
      <BlogPostHeader blogPost={blogPostById} />
      <BlogPostBody blogPost={blogPostById} />
    </div>
  );

ここでは、<BlogPostHeader />と<BlogPostBody />をレンダリングしています。よく見ると、両方とも blogPostByIdオブジェクトを渡してレンダリングしていることがわかるかもしれません。これは、fragmentを展開した ⁶ query内のオブジェクトです。これがRelayでのfragmentデータの転送方法です。fragmentを使用して、コンポーネントにfragmentを展開したオジェクトを渡し、コンポーネントはそれを使って実際のfragmentデータを取得します。心配しないでください、投げっぱなしにはしません。型システムを通じて、Relayは正しいfragmentが展開された正しいオブジェクトを確実に渡します。これについてはもう少し詳しく説明します。

ふー、新しいことがいくつかありましたね。しかし、これまでに見てきたところでは、Relayが私たちを助けるために行っていることの多くを紹介してきましたが、これらのメリットを受けるためには通常は手動で行わなければならないことばかりです。

Relayの規則に従うことで、要求されたデータを持っていないとコンポーネントをレンダリングすることができません。つまり、壊れたコードをプロダクションに出荷するのに苦労することになります。

それでは、コンポーネントのツリーを下に移動していきましょう。

fragmentを使ったコンポーネントの構築

<BlogPostHeader>のコードを示します。

// BlogPostHeader.ts
import * as React from 'react';
import { useFragment } from 'react-relay/hooks';
import { graphql } from 'react-relay';
import { 
  BlogPostHeader_blogPost$key,
  BlogPostHeader_blogPost
} from './__generated__/BlogPostHeader_blogPost.graphql';
import { BlogPostAuthor } from './BlogPostAuthor';
import { BlogPostLikeControls } from './BlogPostLikeControls';

interface Props {
  blogPost: BlogPostHeader_blogPost$key;
}

export const BlogPostHeader = ({ blogPost }: Props) => {
  const blogPostData = useFragment<BlogPostHeader_blogPost>(
    graphql`
      fragment BlogPostHeader_blogPost on BlogPost {
        title
        coverImgUrl
        ...BlogPostAuthor_blogPost
        ...BlogPostLikeControls_blogPost
      }
    `,
    blogPost,
  );

  return (
    <div>
      <img src={blogPostData.coverImgUrl} />
      <h1>{blogPostData.title}</h1>
      <BlogPostAuthor blogPost={blogPostData} />
      <BlogPostLikeControls blogPost={blogPostData} />
    </div>
  );
};

ここでの例では、1つのコンポーネントにつき1つのfragmentしか定義していませんが、1つのコンポーネントは、同じタイプの複数のfragmentを含む任意の数の GraphQLの型で任意の数のfragmentを定義することができます。

分解してみましょう。

import { 
  BlogPostHeader_blogPost$key,
  BlogPostHeader_blogPost
} from './__generated__/BlogPostHeader_blogPost.graphql';

Relay コンパイラが自動生成した BlogPostHeader_blogPost.graphqlファイルから2つの型定義をインポートします。

Relayコンパイラはファイル ⁷からGraphQL fragmentコードを抽出し、型定義を生成します。プロジェクトで作成してRelayで使用するすべてのGraphQLコード（query、mutation、subscription、fragment）に対してこの処理を行います。これは、fragmentの定義が変更されてもコンパイラが自動的に型を同期させることを意味します。

BlogPostHeader_blogPostにはfragmentの型定義が含まれており、それをuseFragment (後ほど詳しく説明します)に渡すことで、fragmentのデータとの対話が型安全になるようにしています。

しかし、12行目のinterface Props { … }にあるBlogPostHeader_blogPost$keyは一体何なのでしょうか？まあ、それは型の安全性に関係しています。本当に今は気にする必要はありませんが、好奇心旺盛な方のためにとりあえず分解してみましょう（そうでない方は次の見出しに飛ばしてください）。

この型定義は、型の黒魔法を使って、正しいオブジェクト（BlogPostHeader_blogPostfragmentが展開されるべき場所）だけをuseFragmentに渡すことができるようにし、間違っている場合はビルド時にエラーを発生させます（エラーをエディタで確認できます！）。ご覧のように、propsからblogPostを受け取りuseFragmentの2番目の引数として渡しています。そして、もしblogPostが正しいfragment(BlogPostHeader_blogPost)を展開していない場合、型エラーが発生します。

全く同じデータを指定した別々のfragmentが同時にそのオブジェクトに展開されていても問題ありません。RelayはuseFragmentを使って、使用したいfragmentが正確に正しいかどうかを確認してくれます。これは重要なことです。他のコンポーネントに暗黙のうちに影響を受けることなく、fragmentの定義を変更できることをRelayが保証する方法の一つだからです。

Relayは正しいフラグメントを含んでいる正しいオブジェクトを渡すことで、間違ったデータソースを参照するようなの潜在的なエラーの原因を排除します。

明示的に指定したデータだけが使用することができる

fragmentとしてBlogPostHeader_blogPostをBlogPost型で定義しました。このコンポーネントには2つのフィールドを明示的に指定しています。

- `title`
- `coverImgUrl`

これは、このコンポーネントでこれらのフィールドを使用しているからです。このことは、Relayの重要な機能のひとつであるデータのマスキングを強調しています。次の展開したfragment ⁸であるBlogPostAuthor_blogPostがtitleとcoverImgUrlを指定していたとしても、自分のfragmentで明示的に要求しない限り、これらのフィールドにアクセスすることはできません（つまり、フィールドは取得の定義を書いた場所でのみ使用されなければなりません）。

これは型レベル（生成された型に明示的に指定されなかったフィールドは含まれません）でも実行時にも適用されます。仮に型システムをバイパスしても、値は存在しません。

最初は少し奇妙に感じるかもしれませんが、これもRelayの安全機構のひとつです。他のコンポーネントが指定したデータに暗黙的に依存することが不可能であることがわかっていれば、他のコンポーネントが奇妙で予期せぬ方法で壊れるリスクを冒すことなく、コンポーネントのリファクタリングを行うことができます。これはアプリが成長していく上で非常に有効です。また、すべてのコンポーネントとそのデータ要件が完全に自己完結するようになります。

コンポーネントが必要とするすべてのデータが明示的に定義されていることは、他のコンポーネントが依存していたqueryやfragmentからフィールドの指定を削除することで、誤ってUIを壊してしまうことがないことを意味します。

  const blogPostData = useFragment<BlogPostHeader_blogPost>(
    graphql`
      fragment BlogPostHeader_blogPost on BlogPost {
        title
        coverImgUrl
        ...BlogPostAuthor_blogPost
        ...BlogPostLikeControls_blogPost
      }
    `,
    blogPost,
  );

ここでは、React hookのuseFragmentを使ってfragmentのデータを取得しています。useFragmentは、フラグメントの定義（graphqlタグの中で定義されたもの）と、そのフラグメントが展開されたオブジェクト（ここではpropsからきたblogPost）を引数から理解し、それを使ってこの特定のフラグメントのデータを取得します。

再度確認しますが、このfragmentのデータ(title/coverImgUrl)は、propsからきたblogPostからは直接取得できません。データは、fragmentの定義とfragmentが展開されたオブジェクトであるblogPostを用いて、useFragmentを呼び出すことでのみ取得できます。

そして、先ほどと同じように、レンダリングしたいコンポーネントのfragmentを展開します。この場合、BlogPostAuthor_blogPostとBlogPostLikeControls_blogPostです。

好奇心のある方へ：fragmentはどのフィールドを指定するかを記述するだけなので、useFragmentは実際にデータをGraphQLのAPIにリクエストすることはありません。fragmentのデータを取得するためには、どこかの時点でquery (または他のGraphQL operation) を実行しなければなりません。しかし、Relayには非常にクールな機能があり、fragmentのデータをRelay自身が再取得できるようになっています。これは、特定の GraphQL オブジェクトをidで再取得するためのqueryをRelayが自動的に生成してくれるからです。話は脱線してしまいましたが…。

また、Redux をご存知であれば、useFragmentをステートツリーから必要なものだけを取得するselectorに例えることもできます。

  return (
    <div>
      <img src={blogPostData.coverImgUrl} />
      <h1>{blogPostData.title}</h1>
      <BlogPostAuthor blogPost={blogPostData} />
      <BlogPostLikeControls blogPost={blogPostData} />
    </div>
  );

明示的に要求したデータ(coverImgUrlとtitle)をレンダリングし、2つの子コンポーネントにデータを渡して、子コンポーネントがレンダリングできるようにします。fragmentを展開するコンポーネントにオブジェクトを渡すことに注意してください。このオブジェクトはfragmentのルートであるBlogPostHeader_blogPostで定義され使用されます。

どうやってRelayはパフォーマンスを維持するのか

fragmentを使用する場合、各fragmentは実際に使用しているデータの更新のみをsubscribeします。つまり、上記の<BlogPostHeader />コンポーネントは、レンダリングしている特定のブログ記事のcoverImgUrlやtitleが更新された場合にのみ、自分自身で再レンダリングを行います。もしBlogPostAuthor_blogPostが他のフィールドを指定し、それらのフィールドが更新された場合でも、このコンポーネントは再レンダリングされません。データの変更はfragmentレベルでsubscribeされます。

これは少し混乱するように聞こえるかもしれませんし、最初はそれほど便利ではないかもしれませんが、パフォーマンスのためには非常に重要なことです。ここでは、クライアントでGraphQLデータを扱う場合の一般的な方法と対比させて、この点について詳しく見ていきましょう。

Relayでは、データが更新されると、更新されたデータを使用しているコンポーネントのみが再レンダリングされます。

ビューで使うデータはどこから来るのか？他のフレームワークとの比較

ビューで使用するすべてのデータは、queryのようにサーバーから実際にデータを取得する操作に由来していなければなりません。queryを定義し、フレームワークにサーバーからそれを取得させ、必要なデータを渡して、ビュー内で必要なコンポーネントをレンダリングします。ほとんどの GraphQLフレームワークでは、データのソースはqueryです。データはqueryからコンポーネントへと流れていきます。他の GraphQL フレームワークで一般的にどのように行われているかの例を示します（矢印はデータがどのように流れるかを表しています）。

注: フレームワークのデータストアは、多くのフレームワークではキャッシュと呼ばれています。この記事では、フレームワークのデータストア === キャッシュと仮定します。

フローは以下のようになります。

<Profile />がquery ProfileQueryを作成し、GraphQL APIにリクエストを発行します。
レスポンスはフレームワーク固有のデータストア (キャッシュ) に何らかの方法で保存されます。
データはレンダリングのためにビューに届けられます。
ビューはその後、データの一部を必要とする子孫コンポーネント（Avatar、Name、Bioなど）に渡し続けます。最後に、あなたのビューはレンダリングされます。

Relayはどのように行うのか

さて、Relayの場合はこれとは全く異なります。Relayの場合はイラストがどうなっているのか見てみましょう。

何が違うのでしょうか？

queryが GraphQL API に発行され、データはフレームワークのデータストアに格納されます。ここまでは同じですが、ここから違いが出てきます。
データを使用するすべてのコンポーネントは、データストア（キャッシュ）から直接データを取得していることに注目してください。これは、Relayのfragmentとの深い統合によるものです。UIでは、各fragmentはフレームワークのデータストアから直接データを取得し、実際のデータがqueryから渡されることには依存しません。
queryから他のコンポーネントの矢印は消えています。queryから一部の情報は、データストアから必要なデータを探すためにfragmentに渡されています。しかし、実際のデータはfragmentに渡されず、全ての実際のデータはfragment自身によってデータストアから取得されます。

以上、Relayやその他のGraphQLフレームワークの仕組みについて、詳しく説明してきました。なぜこれにこだわる必要があるのでしょうか？実は、この設定によりいくつかの優れた機能が利用できるようになります。

他のフレームワークでは通常、データのソースとしてqueryを使用し、そのデータを他のコンポーネントにツリーダウンして渡すことに頼っています。Relayではこれを逆転させ、各コンポーネントがデータストアから必要なデータを取得できるようにします。 ⁹

タダでパフォーマンスが得られる

考えてみてください。queryがデータのソースである場合、queryが持っているデータに影響を与えるデータストアへの更新は、queryを保持しているコンポーネントの再レンダリングを強制します。つまり、データストアの更新によって再レンダリングが発生し、子コンポーネントに渡すために親コンポーネントからデータを取得する以外に、更新とは何の関係もないコンポーネントのいくつものレイヤーを経由してカスケードしなければなりません。

各コンポーネントが必要なデータをストアから直接取得し、使用するデータのみを対象に更新をsubscribeするというRelayのアプローチでは、アプリのサイズや複雑さが大きくなってもパフォーマンスを維持することができます。

これはsubscriptionを使用する際にも重要です。Relayでは、subscriptionから送られてくる更新データが、その更新データを実際に使用しているコンポーネントの再レンダリングのみを発生させるようにしています。

データのソースとしてqueryを使用すると、GraphQLのキャッシュが更新されたときにコンポーネントツリー全体が再レンダリングされることになります。

モジュール化と独立性は、安全にリファクタリングできることを意味する

queryからデータを実際に必要とするコンポーネントにデータをルーティングする責任を開発者から取り除くことで、開発者が物事を台無しにする機会がなくなります。queryのデータにアクセスできないということは、コンポーネントツリーを通過しているはずのデータに誤って(あるいはもっと悪いことに、意図的に)依存してしまう ¹⁰ということはあり得ません。Relayはあなたのためにヘビーな作業を代行してくれます。

Relayとそのfragmentファーストのアプローチを使うことで、コンポーネントツリー内のデータフローを混乱させることは非常に難しくなります。

もちろん、「queryをデータのソースとして使用する」アプローチの欠点のほとんどは、React.memoやshouldComponentUpdateなど、昔ながらの手動での最適化によって多少は緩和されることには注意が必要です。しかし、これはそれ自体がパフォーマンスの問題になる可能性があるだけでなく、ミスを起こしやすいという欠点があります（タスクが面倒であればあるほど、人間は最終的にそれを台無しにしてしまう可能性が高くなります）。一方、Relayは、そんなことを考えなくてもパフォーマンスを維持できるようにしてくれます。

各コンポーネントがキャッシュから独自したデータを受け取ることで、ビューのフルデータが戻ってくるのを待っている間に、すでにストアで利用可能なデータを使ってビューを部分的にレンダリングするなど、Relayの非常にクールで高度な機能を利用することができます。

fragmentのまとめ

ここで少し立ち止まって、Relayがどのようなタイプの作業をしてくれているのかをダイジェストで見てみましょう。

型システムを通じて、Relayは対象のコンポーネントが正確な使い方の正しいGraphQLのデータなしではレンダリングできないことを確認しています。これで失敗が一つ減りました。
fragmentを使用する各コンポーネントは、使用するデータが更新された場合にのみ正確に更新されるため、Relayではデフォルトで高いパフォーマンスが得られます。
型を生成することで、Relayはfragmentから得られたデータとの対話が型安全であることを保証しています。ここで注目すべきは、型生成はRelayコンパイラの中核機能であるということです。

Relayのアーキテクチャと哲学では、コンポーネントのデータ依存関係からサーバが提供するデータとその型に至るまで、コンポーネントに関する多くの情報をコンピュータに提供しています。これらすべての情報を利用して、通常であれば開発者である私たちが処理しなければならないようなあらゆる作業を行います。

ビューが複雑になる速度を過小評価するのは簡単です。複雑さとパフォーマンスは、Relayが強制的に従わせる規則によってデフォルトで処理されます。

これにより、開発者には大きな力がもたらされます。

ほぼ完全に分離された組み合わせ可能なコンポーネントを構築することができます。
コンポーネントのリファクタリングは完全に安全で、Relayは何かを見逃したり、台無しにしたりすることがないようにしてくれます。

再利用可能なコンポーネントを数多く作り始めると、その重要性は過大評価されることはないでしょう。コードベースの大部分で使用されるコンポーネントのリファクタリングが安全であることは、開発者のベロシティにとって非常にクリティカルです。

アプリが成長するにつれて、リファクタリングの容易さと安全性は、高速に開発し続けるために非常に重要になってきます。

Relayの紹介を締めくくる

この記事では多くのことを取り上げました。この記事から何かを得たとするなら、Relayは、保守やリファクタリングが簡単で型安全な、スケーラブルでパフォーマンスが高いアプリケーションを構築することを強制しているということです。

Relayは実際にあなたのために泥臭い仕事を肩代わりしてくれます。そして私たちが示した多くのことは、他のフレームワークを使っても英雄的な努力を通して達成することができますが、私たちはこれらのパターンを強制することがもたらすことができる強力な利点を示したことを願っています。それらの重要性は誇張ではありません。

注目に値するソフトウェア

Relayは、血と汗と涙、そして何よりも重要な、長い間GraphQLを使って製品を出荷したりメンテナンスしたりしてきた経験と深い洞察力をもとに構築された、注目に値するソフトウェアです。

この記事はかなり長く、かなり濃い内容になっていますが、Relayで何ができるのかについてはまだほんの少ししか触れていません。この記事の最後に、この記事では取り上げていないRelayでできることの詳細をいくつか挙げておきましょう。

楽観的で複雑なキャッシュ更新によるmutation ¹¹
subscription
SuspenseとConcurrent Modeと完全に統合されており、次世代のReactに対応しています。
Relayを使ってローカルな状態を管理することで、Relayをローカルな状態管理にも使えるという一般的なメリットを享受できます（SuspenseとConcurrent Modeとの統合など！）。
リストの結果を@stream経由でストリーミングできます
サーバレスポンスの読み込みに時間がかかる部分を@deferで遅延させることで、残りの UI をより高速にレンダリングできるようにします。
fragmentの再取得とページネーションのためのqueryの自動生成
複雑なキャッシュ管理：キャッシュのサイズを制御し、ビューのデータをキャッシュを使用するかネットワークから取得するかを制御します (またはその両方、または最初にキャッシュを実行してからネットワークを実行します)。
安定した成熟した柔軟なキャッシュ。本当に安定して動きます。 ¹²
ユーザーがナビゲーションの開始を示すと、すぐに新しいビューのqueryをプリロードします。queryデータが到着するのを待っている間に、ストアですでに利用可能なデータを使ってビューを部分的にレンダリングします。
fragmentの引数（コンポーネントのpropsのようなもの）を定義することで、コンポーネントの組み立てを次のレベルに引き上げることができます。
スキーマから得られるデータよりも、グラフ内のデータがどのように接続されているのかをRelayに教えることで、キャッシュからより多くのデータを解決できるようにします（「ある変数を持つトップレベルのフィールドは同じUserを解決できる」と考えてください）。

この記事はここまでですが、Relayのページネーションに関する記事もぜひ読んでみてください。Relayページネーション編では、Relayのパワフルな機能を美しい方法でまとめ、フレームワークにすべての作業を任せることで、どれだけの自動化と驚くべきDXが可能になるのかを紹介しています。詳細はこちらをご覧ください。

他にも続けて読める記事をいくつかご紹介します。

Nodeインターフェイスの魔法。Node インターフェース、グローバルに一意な ID、そしてそれらがもたらす力についての記事。
Connectionベースのページネーション。Connectionベースのページペーションがなぜ良いアイデアなのかについての紹介。

お読みいただきありがとうございました！

スペシャルサンクス

この記事の草稿への徹底的なフィードバックをしてくれた Xavier Cazalot, Arnar Þór Sveinsson, Jaap Frolich, Joe Previte, Stepan Parunashvili, Ben Sangster に感謝します!

訳注：翻訳の許可をくれたGabriel、ありがとう。あんた最高だぜブラザー。
↩
訳注：2020年8月現在、ReactのSuspenseとConcurrent Modeはexperimental buildでのみ利用可能です。 https://ja.reactjs.org/docs/concurrent-mode-adoption.html hooksなどのRelayのexperimental版にしかないAPIも同様です。
↩
訳注：2020年5月にrelayで作ったfacebookはリリースされました。
↩
訳注：GraphQLのoperationとは、QueryまたはMutation、Subscription、Fragmentのことです。
↩
訳注：全体が1つのグラフになっているので、blogフィールドの中にauthorフィールドがあると考えられます。そうなると、authorフィールドのサブフィールドがfirstNameなどであると考えられます。ここでは要するに、最小単位でまとめられるためにあらゆるコンポーネントのデータを定義できるということです。
↩
訳注：spreadを展開と訳していますが、ここで言う展開とはスプレッド演算子（…）を使用してfragmentのフィールドをクエリに展開することを言っています。fragmentのデータが展開されるわけではありません。
↩
訳注：BlogPostHeader.tsのこと。鶏と卵のように聞こえるかもしれませんが、まずBlogPostHeader.tsにqueryを書いてコンパイルすると型定義のファイルが作られるので、それをimportしてレンダリングするコードを書きます。
↩
訳注：次というのはBlogPostHeader_blogPostの子要素ということ
↩
訳注：ここで言うツリーダウンとは、親要素から子要素へ、子要素から孫要素へとツリーを降りながらデータを渡すことです。
↩
訳注：別のコンポーネントが要求して自身が明示的に要求していないデータに依存していると、別のコンポーネントが何らかの理由でそのデータを取得しない場合（もっと悪いとコンポーネントが消えた場合）にデータが欠損します。こうした事象を長期的に手動で完全にコントロールすることは非常に困難です
↩
訳注：楽観的（optimistic）なキャッシュ更新とは、更新時にサーバー側のレスポンスを待たずにキャッシュを更新することです
↩
訳注：原文はJust Works (TM) 。知らなかったので本人に聞いたら、Just Works (TM) is a joke. People often refer to software/hardware that’s really stable like “it just works” だそうです。ギャグの解説させてしまってごめん。
↩

nakamoriのblog

Apollo Clientにいろいろ足しながらRelayと比較する

私の状況

Apollo Client vs Relay の概況

Apollo Clientにいろいろ足しながらRelayと比較する

Apollo Clientだけ vs Relay

Apollo Client + GraphQL Code Generator vs Relay

Apollo Client + GraphQL Code Generator + Nau vs Relay

まとめ

Apollo Clientの強みと弱みを考える

Apollo Clientの良いところ

Apollo Clientの良くないところ

対応策

Apollo Clientの弱みと向き合う

Relay Meetup #2 レポート

Relay Meetupについて

1. Relay関連のニュース

Relay 10.1.0リリース

meros

Graphql Helix

2. Relay Workshop

3. @deferと@stream

まとめ

Relay Meetup #1 レポート

オンラインでの開催

1. Relayコミュニティからのニュース

2. ArtsyでのRelayについて

3. Mutationでのキャッシュアップデートについて

まとめ

インフラをコード化するPulumiを実運用している話

むかし話

YAMLでリソースを作るの大変すぎ問題

そしてPulumiへ

Pulumiを実運用した感想

良いところ

微妙なところ

まとめ

リッチテキストエディタを作れるSlate、2020年の状況

私がSlateを使い始めた理由

現在のSlateの状況

作者不在

日本語入力のサポートはまだ厳しい

どうなるAndroidサポート

プラグインは超前進

私のこれから

ブログを（ここに）移行しました

移行した理由

何でできているか

最近のお仕事

React.Suspenseの力を最大化する、GraphQLの次世代ディレクティブ @ defer と @ stream

Suspenseは最高だ！

ダメだキャッシュがない

RESTやGraphQL（旧）の問題点

データに優先度をつけてインクリメンタル配信する

インクリメンタル配信を行う@deferと@stream

1つのリクエスト、複数のレスポンスの実装

現在の進捗

おまけ：実際のクエリ

GraphQLを検討中のあなたに送るQ&A集

はじめに編

GraphQLの素晴らしいところは何ですか

フロントエンド編

フロントエンドにどんなメリットがありますか

Reduxなどの状態管理のソフトウェアを使う必要がありますか

ApolloとRelayどちらが良いですか

他に有名なGraphQLクライアントはありますか

TypeScriptと相性は良いですか

一回で色々なオブジェクトを取得するのでUIの表示が遅くなりませんか

バックエンド編

バックエンドにどんなメリットがありますか

APIに型をつけるという観点で、GraphQLとXXX（好きなソフトウェア）と違いはありますか

スキーマファーストとコードファーストのどちらが良いですか

CDNでキャッシュが効かないと聞きましたが本当ですか

N+1は発生しますか

1発であらゆるオブジェクトが取得できるって負荷やばくないですか

エラーが発生したのに200を返すのはおかしいと思います

どうやって認証しますか

RESTのAPIと共存できますか

Relay Server Specificationに準拠する必要がありますか

node(id)フィールドは神APIではないですか

`Apollo Client` vs `Relay` の概況

`Apollo Clientだけ` vs `Relay`

`Apollo Client + GraphQL Code Generator` vs `Relay`

`Apollo Client + GraphQL Code Generator + Nau` vs `Relay`

インクリメンタル配信を行う`@defer`と`@stream`

`node(id)`フィールドは神APIではないですか

そもそも`Node`インターフェースとは何か？

なぜグローバルに一意なIDなのか？整数で十分では？

テンプレは意思決定をなくし、ときめき⁴をもらたす他のものに集中することができる

ビューで使うデータはどこから来るのか？他のフレームワークとの比較