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.8k
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 株式会社カミナシ
プロダクト進化とグロースを加速させる「強いCS組織」の秘訣 / The secret to a strong customer service organization that accelerates product evolution and growth
kaminashi
0
9
"サービスチーム" での技術選定 / Making Technology Decisions for the Service Team
kaminashi
1
230
「チームで勝つ」カミナシCSのミッションとチーム作り / "Win as a team" - Kaminashi CS's mission and team building
kaminashi
0
110
TypeScript と歩む OpenAPI の discriminator / OpenAPI discriminator with TypeScript
kaminashi
1
230
新規事業におけるプロダクトロードマップ のFit & Refine / Fitting and Refine Product Roadmaps for New Businesses
kaminashi
0
360
結局オブザーバビリティってなんやねん / So, what the heck is observability anyway?
kaminashi
0
110
ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか / What can a single engineer do to connect business, design, and engineering?
kaminashi
2
1.4k
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
13
10k
AWSで作るセキュアな認証基盤with OAuth mTLS / Secure Authentication Infrastructure with OAuth mTLS on AWS
kaminashi
0
280
Other Decks in Technology
See All in Technology
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
190
Zephyr RTOSを使った開発コンペに参加した件
iotengineer22
1
200
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
290
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
6
4.1k
OPENLOGI Company Profile for engineer
hr01
1
34k
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
270
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
180
Connect 100+を支える技術
kanyamaguc
0
190
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
290
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
2
6.3k
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
1
240
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
27k
Featured
See All Featured
Bash Introduction
62gerente
614
210k
Six Lessons from altMBA
skipperchong
28
3.9k
4 Signs Your Business is Dying
shpigford
184
22k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
GraphQLとの向き合い方2022年版
quramy
49
14k
It's Worth the Effort
3n
185
28k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Building an army of robots
kneath
306
45k
Thoughts on Productivity
jonyablonski
69
4.7k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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さんなら選択を正解にしてくれると信じてます 今のフロントエンドの技術選定は何を選んでも(あるいは選ばなくて も)将来反省や後悔となるものはきっと出てくるはず。 技術選定そのものの良し悪しではなく、その後のプロダクトや設計を 良くしていこうとする、情熱やコミットメントやオーナーシップこそ
を大切にしていきたいと考えています。