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
6
1.1k
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 株式会社カミナシ
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
190
開発者が自律的に AWS Security Hub findings に対応する仕組み / How developers can self-remediate AWS Security Hub findings
kaminashi
1
100
実践ゼロから作らないデザインシステム SaaS × デザインシステム × プロダクトデザイン / Efficient Design System for SaaS—no need to start from scratch.
kaminashi
2
1.1k
プレイングマネージャーは本当に悪なのか? 令和時代のプレイングマネージャーを戦略的にハックする / Re-thinking the Accountability of Playing Manager
kaminashi
8
4.1k
BtoB プロダクトにおけるインサイトマネジメントの必要性 現場ドリブンなカミナシがインサイトマネジメントに取り組むワケ / Why field-driven Kaminashi is working on insight management
kaminashi
1
360
“受動型”から“先導型”カスタマーサクセスへの変革 / Transforming from “Reactive” to “Proactive” Customer Success
kaminashi
0
78
マルチプロダクト戦略を加速させる! ゼロダウンタイムで挑んだID管理機能移行の道のり / The Journey of Migrating ID Management Features with Zero Downtime
kaminashi
2
480
とある EM の初めての育休からの学び / Lessons from an EM's first parental leave
kaminashi
0
260
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
390
Other Decks in Technology
See All in Technology
ClineにNext.jsのプロジェクト改善をお願いしてみた / 20250321_reacttokyo_LT
optim
1
1.2k
パスキーでのログインを 実装してみよう!
hibiki_cube
0
580
RAGの基礎から実践運用まで:AWS BedrockとLangfuseで実現する構築・監視・評価
sonoda_mj
0
410
EM初心者として半年間マネジャーをやってみて分かったこと
sansantech
PRO
0
200
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
180
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
610
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
1.9k
開発組織全体で意識するSLI/SLOを実装している話
zepprix
1
760
目次機能実装から理解するLexical Editor
wtdlee
0
130
技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025
shogogg
7
1.7k
AI・LLM事業部のSREとタスクの自動運転
shinyorke
PRO
0
280
ルートユーザーの活用と管理を徹底的に深掘る
yuobayashi
6
690
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
How to Ace a Technical Interview
jacobian
276
23k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Applications with DynamoDB
mza
94
6.3k
Producing Creativity
orderedlist
PRO
344
40k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
BBQ
matthewcrist
88
9.5k
Building Your Own Lightsaber
phodgson
104
6.3k
Building a Modern Day E-commerce SEO Strategy
aleyda
39
7.2k
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さんなら選択を正解にしてくれると信じてます 今のフロントエンドの技術選定は何を選んでも(あるいは選ばなくて も)将来反省や後悔となるものはきっと出てくるはず。 技術選定そのものの良し悪しではなく、その後のプロダクトや設計を 良くしていこうとする、情熱やコミットメントやオーナーシップこそ
を大切にしていきたいと考えています。