Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
React Server Componentは 何を解決し何を解決しないのか / What d...
Search
株式会社カミナシ
March 28, 2025
Technology
8
1.9k
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
2025/03/28
ゆめみ ✖️ カミナシのフロントエンドLT会
React Server Componentは 何を解決し何を解決しないのか
osuzu
ソフトウェアエンジニア
株式会社カミナシ
March 28, 2025
Tweet
Share
More Decks by 株式会社カミナシ
See All by 株式会社カミナシ
Sentry初心者が便利だなと思ったポイントと活用事例 / Helpful Points and Use Cases for Sentry Beginners
kaminashi
0
51
読書会から始める関数型ドメインモデリング / Learning Functional Domain Modeling Through a Reading Group
kaminashi
3
98
プロダクト進化とグロースを加速させる「強いCS組織」の秘訣 / The secret to a strong customer service organization that accelerates product evolution and growth
kaminashi
0
130
"サービスチーム" での技術選定 / Making Technology Decisions for the Service Team
kaminashi
1
370
「チームで勝つ」カミナシCSのミッションとチーム作り / "Win as a team" - Kaminashi CS's mission and team building
kaminashi
0
130
TypeScript と歩む OpenAPI の discriminator / OpenAPI discriminator with TypeScript
kaminashi
1
310
新規事業におけるプロダクトロードマップ のFit & Refine / Fitting and Refine Product Roadmaps for New Businesses
kaminashi
0
430
結局オブザーバビリティってなんやねん / So, what the heck is observability anyway?
kaminashi
0
130
ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか / What can a single engineer do to connect business, design, and engineering?
kaminashi
2
1.5k
Other Decks in Technology
See All in Technology
Power Automate のパフォーマンス改善レシピ / Power Automate Performance Improvement Recipes
karamem0
0
270
新規事業におけるAIリサーチの活用例
ranxxx
0
170
PdM業務における使い分け
shinshiro
0
670
[MIRU2025]Preference Optimization for Multimodal Large Language Models for Image Captioning Tasks
keio_smilab
PRO
0
100
OpenTelemetry の Log を使いこなそう
biwashi
5
1.1k
MCPと認可まわりの話 / mcp_and_authorization
convto
2
290
興味の胞子を育て 業務と技術に広がる”きのこ力”
fumiyasac0921
0
290
Shadow DOM & Security - Exploring the boundary between light and shadow
masatokinugawa
0
760
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
180
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
370
AI工学特論: MLOps・継続的評価
asei
10
2k
Step Functions First - サーバーレスアーキテクチャの新しいパラダイム
taikis
1
280
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
How GitHub (no longer) Works
holman
314
140k
Gamification - CAS2011
davidbonilla
81
5.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Site-Speed That Sticks
csswizardry
10
720
Optimizing for Happiness
mojombo
379
70k
Speed Design
sergeychernyshev
32
1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Bash Introduction
62gerente
613
210k
Transcript
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さんなら選択を正解にしてくれると信じてます 今のフロントエンドの技術選定は何を選んでも(あるいは選ばなくて も)将来反省や後悔となるものはきっと出てくるはず。 技術選定そのものの良し悪しではなく、その後のプロダクトや設計を 良くしていこうとする、情熱やコミットメントやオーナーシップこそ
を大切にしていきたいと考えています。