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.7k
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 株式会社カミナシ
TypeScript と歩む OpenAPI の discriminator / OpenAPI discriminator with TypeScript
kaminashi
1
120
新規事業におけるプロダクトロードマップ のFit & Refine / Fitting and Refine Product Roadmaps for New Businesses
kaminashi
0
180
結局オブザーバビリティってなんやねん / So, what the heck is observability anyway?
kaminashi
0
100
ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか / What can a single engineer do to connect business, design, and engineering?
kaminashi
2
1.3k
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
12
9.6k
AWSで作るセキュアな認証基盤with OAuth mTLS / Secure Authentication Infrastructure with OAuth mTLS on AWS
kaminashi
0
230
定性データ、どう活かす? 〜定性データのための分析基盤、はじめました〜 / How to utilize qualitative data? ~We have launched an analysis platform for qualitative data~
kaminashi
6
970
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
310
開発者が自律的に AWS Security Hub findings に対応する仕組み / How developers can self-remediate AWS Security Hub findings
kaminashi
1
450
Other Decks in Technology
See All in Technology
Introduction to Bill One Development Engineer
sansan33
PRO
0
230
Project Referencesを活用した実行環境ごとのtsconfig最適化
itatchi3
1
240
RDRA3.0を知ろう
kanzaki
2
400
iOS/Androidで無限循環Carousel表現を考えてみる
fumiyasac0921
0
120
Streamline Cloud-Native App Development Using CDEs
saeedzf
0
640
グループ ポリシー再確認 ③
murachiakira
0
150
ソフトウェアは捨てやすく作ろう/Let's make software easy to discard
sanogemaru
10
5.3k
OSMnx Galleryの紹介
mopinfish
0
140
プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
3
140
JNation 2025 - Quarkus for Spring Developers
edeandrea
PRO
0
100
LT:組込み屋さんのオシロが壊れた!
windy_pon
0
220
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
8
65k
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
The Pragmatic Product Professional
lauravandoore
34
6.7k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.3k
The Cost Of JavaScript in 2023
addyosmani
49
8k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Designing for humans not robots
tammielis
253
25k
How to Ace a Technical Interview
jacobian
276
23k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
740
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
4 Signs Your Business is Dying
shpigford
183
22k
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さんなら選択を正解にしてくれると信じてます 今のフロントエンドの技術選定は何を選んでも(あるいは選ばなくて も)将来反省や後悔となるものはきっと出てくるはず。 技術選定そのものの良し悪しではなく、その後のプロダクトや設計を 良くしていこうとする、情熱やコミットメントやオーナーシップこそ
を大切にしていきたいと考えています。