RSCやAppRouterはGraphQLの正統進化で、resolverがJSXを返すようなもの

@koushisa: Next.jsのfetch拡張はGraphQLのresolverを、GraphQLに依存しない形で作れる未来を目指している気がする

スレッドに続く

ベストプラクティスのひとつであるコロケーションでGraphQLを実装すると、

レスポンスの階層とコンポーネントは1:1に近い形になる

UIの構築で複数のデータソースを使う通信でnetwork waterfallを起こさず（理想的には）一発で取れる

一方、GraphQLのレスポンスがコンポーネントの求める構造と完全に一致することは稀で、どのみちUIの視点でデータ構造を変換する処理は必要となる

React Server Componentsはクライアントと近い位置で概念データをコンポーネント向けに整形できる

APIを介さずDBファーストな選択も可能で、実装詳細の範囲の捉え方次第ではあるが適合可能性が高まる場合もある

blitzに近い感じkoushisa.icon

GraphQLとの対比

GraphQL自体REST APIの弱点を解決するためのもの

Resolver(GraphQL)をクラサバのクッションにしてる

RSCもREST APIの弱点は大体カバーしてる

概念スキーマ→外部スキーマの変換をGraphQL内で行うか、RSCへCompositionさせるかが異なる

RSCにデータ構造の知識をもたせすぎると、クラサバが密結合となってしまう

2023/05/20

@adwd118: GraphQLの有用性ってNext.js App Routerで結構変わるかも？fetchがdedupやcacheをやるしRSCでバックエンドとの複数の通信がクライアントから見ると1回になるんでそれってGraphQLサーバーのresolverがやってることと大体同じというか

2023/06

2023/11/06

REST, RPC, GraphQLからのApp Routerの流れに対する技術の螺旋の見解がほぼ同じだkoushisa.icon

GraphQL + RelayなプロジェクトでもApp Routerに移行するそう

2023/12/25