Next.jsのapp directoryについて話していて、GraphQLを使う場面ではServer Componentsの魅力がいくらか落ちるよな、と思った。裏を返せば、Server Componentsが活用されるような時代ではGraphQLの重要度が下がるかもしれない。
現にServer ComponentsのRFCの「Credits and Prior Art」を見ると次のように書いてある。
- Relay’s data-driven dependencies, which allow the server to dynamically choose which Client Component to use.
- GraphQL, for demonstrating one approach to avoiding multiple round trips when loading data for client-side apps.
GraphQLやRelayは「Prior Art」だ。
GraphQLが強力な理由に、データのグラフがそのまま扱えることや、フラグメントによってコンポーネントが必要とするデータを宣言的に表現できることがある。これらによって解決された課題は、Server Componentsでも解決できる。Server Componentsはサーバーで構築されるから、Web APIを複数回にわたって呼び出す際のRTTが十分に短くなるし、それぞれのコンポーネントで必要なデータを個別に取得してもそれなりにいい感じになる。
ということで、Server Componentsを前提とすると、GraphQLによって得られていた利益（の一部）が他の手段でも叶えられることになる。またはGraphQLを前提とすると、Server Componentsによって得られるはずの利益が多少は目減りする。
もちろんServer Componentsによって達成されることは他にもあるし、GraphQLにも他にメリットがある。
GraphQLは引き続き有力
GraphQLの重要なメリットに、オーバーフェッチングを防ぐことがある。またエコシステムの発展のおかげで、ツーリングも優れている。ネイティブアプリからも利用でき、ひとつのAPIで多様なクライアントをサポートできる。GraphQLはWeb APIを構築する際に、引き続き有力な選択肢である。
またGraphQLの側も@deferや@streamディレクティブによって、Next.jsのStreamingと同じ課題を解決しようとしている。ふたつの技術がある意味では競合するという例でもある。
しかし、RelayやApollo Clientの強力なキャッシュ機構を今のServer Componentsと組み合わせてうまく動かすのはややこしいだろう。と言いつつ、先のページのFAQに「Does this replace Apollo, Relay, or other GraphQL clients for React?」というのがあり、そこでは「No」という回答に加えて、次のようにある。
For example, internally we use Relay and GraphQL in conjunction with Server Components.
つまり詳細はわからないがFacebookでは何らかうまくやっているようである。ただし直感的には、urqlとか、ややライトウェイトなクライアントが取り回しやすい、みたいなことが起きるんじゃないかという気はする。もちろんRelayやApollo Clientの側もさらに進歩して、適応していくだろう。
Server Componentsの時代
ということでServer Componentsの時代では、これまでのクライアントサイドレンダリング（+1ページ目はサーバーサイドレンダリング）のような、クライアント側でやっていくスタイルから変化し、GraphQLの意味付けも変わっていく予感がある。より単純なクライアントが好まれるようになったり、そもそもGraphQLではなくRESTあるいはRPCスタイルのWeb APIが流行るかもしれない。
