React Server Componentは 何を解決し何を解決しないのか osuzu ゆめみ&カミナシのフロントエンドLT会 @20250328 

カミナシでは 新規プロダクトなど一部で Next.js App Routerを採用しています。 今日はReact Server Componentを 実際に運用した感想ベースでお伝えします。 

解決したこと.1 同期的に書けるの最高すぎ 

同期的に書けるの最高すぎ RSCで書ける範囲では、Reactが別のフレームワークになったような 快適さがあります。 今回アプリを構築して感じたが、体感的にこれまでの8割くらいは hooksを使わなくて良くただのTS関数になりました。最高。 同期的に書けるだけでこんな考慮事項減るんだなとあらためて感じる 場面がたくさんあります！ 

解決してないこと.1a 状態が複雑なフォーム等は難しいまま 

状態が複雑なフォーム等は難しいまま フォームなどクライアントで複雑な状態をもつ場合に、 例えばドーナツ状のコンポーネント構成でRSCを利用したりはできる が、結局RSCペイロードにのせる意味が薄かったりと、フォーム全体 をClientコンポーネントで取り扱うことになるケースが多いです。 そうすると、結局React（フロントエンドと言っても良い）で一番難 しくなりやすい複雑なフォームの状態管理などでは、 React Server Componentは何も解決していない。難しいままです。 アプリケーションの困難さの殆どがフォームの複雑な状態管理になる ドメインでは、RSCを採用しても驚くほど何も楽にならないかもw 

解決してないこと.1b Client Fetchのアンサーがない 

Client Fetchのアンサーがない RSCの思想では、冪等なコンポーネントをサーバーでレンダリングし てdataをfetchすることが基本であり、それ自体は良いし、ベストプ ラクティスだと思います。 しかし無限スクロールとか、URLで表現できない検索とか、ボタンを 押してから同じページで重たいリソースをfetchしたいとか、Client fetchをしたくなる場面は出くわすはず。 このClient Fetchをどうするかについて、RSC側もFetchライブラリ 側もお互いの領域を決めかねてる印象があり、どういったオプション を選ぶか自身でトレードオフ考え決める必要があります。 （純粋にTanstack Queryに乗れば良いだけだった時代より難しく なってる印象がある） 

解決したこと.2 APIアグリゲーション快適すぎ 

APIアグリゲーション快適すぎ RSCによるレンダリングやServer Function(Server Action)、いずれ も直感的＆素直に書いてるだけで快適アグリゲーションでboomer fetchingといった問題を回避できます。 APIをリソースサーバーとして運用しやすくなったり、マルチプロダ クト（マイクロサービス）の連携などやはりBFFとして便利なのに、 その構築にほぼ手間がないです。 Clientのバンドルサイズを削りやすいなどの メリットもあるし、 今回私が構築したアプリケーション（SaaSの ユーザー用管理画面）では、 何一つ対策や工夫をせずスコアがAll100。 

解決してないこと.2a パフォーマンスの追求は感じるが クライアントN+1のリスクなど残ってる 

パフォーマンスの注意点 next/linkはデフォルトで画面内のLinkコンポーネント先のRSCを prefetchする機能を持っています。 これはうまく使うと、一瞬で読み込まれたページを表示する凄まじい パフォーマンスの体験を提供することも可能ですが、 予期せずログアウトボタンをprefetchしちゃったり、リストのリンク をすべてprefetchしてしまいAPIアグリゲーションしたのに、結局 ClientでN+1になってるみたいなケースもありえます。 （DataLoaderのようなテクニックや回避策もありますが） みんなが口を揃えるキャッシュの難しさなども含め、パフォーマンス の理想像を追い求めて難しくなってたり、デフォルトのケースとして これまでのStatic Generationを実現しようとしており、Dynamicレ ンダリングでは注意事項や難しさがやはり多く感じます。 

解決してないこと.2b プラットフォームが限られるし ベターGraphQLになりきれてない 

プラットフォームの問題 RSCやServer Actionsの開発体験を一度味わうと、GraphQLは余計な 層だなと感じてしまいますが、やはりRSCにはアーキテクチャ上の制 約があります。 ExpoやReact NativeでRSCを動かすみたいな話もありますが、やはり マルチプラットフォーム展開を考える場合やNextやReactに依存し過 ぎたくない場合、GraphQLのような活用は望めません。 またこれまでGraphQL（に限らず良いBFF）を運用してきたり知見を 貯めてきた組織にとって、わざわざアーキテクチャ上のリスクや活用 の幅を狭める可能性の高いRSCを採用することが良いとは私も思えま せん。 

結局 React Server Component は良かったの？ 

React Server Componentに寄せて なんかマイナス感想のが多くないか？？ でも私的には、React Server Componentは良かったです！ （もちろん要件次第で銀の弾丸からは程遠いが…）また使いたい！ 同期的に書けるReactは、 実際に書いてみるとReactが別のフレームワークになったような 書きやすさを感じます。 それこそ初めてhooksを使ったときに似た書き心地の向上体験。 しかも工夫せず素直に書くだけで、パフォーマンスも良くなりやす かったです。 

React Server Componentに寄せて 一方でRSCを使うにあたって現状ファーストチョイスである Next.jsに対しては色々ハマったところや不満もあります。 RemixやTanstackがRSCに対する完成度高いフレームワークを出し て、選択可能な状況になって欲しいですが… ただし現状でRSCを採用しようと思うと、Next.jsと独立したり依存し ないような構築は困難です。どこまでがApp Routerの果たす役割で どこまでがRSCなのかの線引きは非常に曖昧。 （せめてNext.jsがViteを採用してくれていれば…🥲 　一度に色んなことやりすぎてしまった感） 

React Server Componentに寄せて Evanさんの今日のツイート 「RSCを銀の弾丸にしようとしたReactチー ムとNextチームの賭けは失敗したと思う」 — 以下私見 私はRSCを好きだし良いと思いますが、それで も、何年も未完成でいつになったら完成系になる かすら分からないし、アーキテクチャ的に選択で きないチームも多いはずです。 Reactに依存しすぎないよう設計するという意見 やスタンスも現代では一つの正解だと思います。 Reactと独立したレイヤー用意してロジックまと めたり、jotaiやTanstackなどReactと独立したも のに状態やロジックをまとめていくなど。 

さいごに カミナシではDesign Docをレビューしあう文化があり、 今回のアーキテクチャを相談した時、CTOから言われた一言 > osuzuさんなら選択を正解にしてくれると信じてます 今のフロントエンドの技術選定は何を選んでも（あるいは選ばなくて も）将来反省や後悔となるものはきっと出てくるはず。 技術選定そのものの良し悪しではなく、その後のプロダクトや設計を 良くしていこうとする、情熱やコミットメントやオーナーシップこそ を大切にしていきたいと考えています。