React Server Componentのハンズオンを作ってみて考えたこと
皆さんこんにちは。
React Server Component（以下、RSC）のキャッチアップはしていますでしょうか？
React19 RCのアナウンスによると、RSCのユーザーランドでのマイナーバージョン間での破壊的変更は無いそうです。（非ユーザーランド＝バンドラ向けのAPIは変わるそうですが）
一旦今の仕様で問題無いと判断したということだと思います。自分としても今の仕様は学習曲線がゆるやかで、良くできていると思います。
Next.jsを利用すればプロダクションとして採用できないこともないフェーズに入っていて、他にもRemixやWaku（Viteベース）など、将来的な選択肢は増えていくでしょう。
この状況を鑑み、すでに学習に入る分には問題無いと思い、RSCのハンズオンを作成しました。
こちらがリポジトリです。
対面で説明を受けながらが効果的ですが、読み物としてもある程度は成立するようにしました。
当記事では、自分がハンズオンを作りながらRSCについて考えたことを綴ります。（ハンズオン本体はリポジトリをご覧ください）
実際のところ、この記事を開いていただいた皆さんにハンズオンを共有したかっただけなので、ここで終わりたい気分ですが…
RSCの真髄はどこにあるのか
RSCの真髄は、Webアプリケーションが真にモノリスなシステムとして開発できるようになる点にあると思います。
今まではWebアプリケーションには２つのシステムが必要でした。
"バックエンド"として開発されるデータ提供のシステムと、"フロントエンド"として開発されるデータ活用のシステムです。
その間をつなぐのがWebAPIとしての通信エンドポイントで、強い境界があったわけです。
RSC（ひいてはサーバーアクション）はその境界を隠蔽してしまうため、バックエンドとフロントエンドは一つの共通のシステムを開発対象にしていくことになります。
この「境界の隠蔽」をもっと分かりやすく「通信エンドポイントが自動生成される」と言い換えても良いと思います。
クライアントとサーバーの通信が必要である以上、エンドポイント自体が無くなることはありませんが、自動生成されるのであれば我々が設計する必要もないわけで、RSCではその代わりにサーバーアクションを定義していくことになるわけです。
自動生成は、今のところバンドラがコンパイル時に行うため、これは「言語レベルでのサポート」と言っても良いでしょう。
我々が気づかないだけで、言語レベルでサポートされていることは今でもいくらでもあるわけです。
例えば、ガベージコレクションは、今では言語のシンタックスから自動で最適化され、実行されています。
今の時代にプログラミングを始めたエンジニアがガベージコレクションに頭を悩ませることはほとんど無いでしょう。
それと同じで、（外部システムとの連携を除けば）APIの設計に頭を悩ませることもほとんど無くなると思います。
RSCは破壊的な技術なのか
実際のところ、今まで通りAPIサーバーは維持しつつ、新機能をRSCで構築していくなどの共存形態は比較的簡単に実装できるため、RSCを入れても劇的な変化を強制されるわけではありません。
今までのコンポーネントはクライアントコンポーネントとして扱えば同等の扱いができるため、移行も簡単でしょう。
しかしそれは、超ハイスペックな家電を買ったけど、箱から出さずに部屋の隅に置いておくような勿体なさがあります。
「新しい機能はRSCで作る」などで徐々に適応していくと良いでしょう。
また、RSC導入における障害は、技術やコード面での変化よりも、開発体制への影響が大きいのではないかと僕は感じています。
RSCは未来のスタンダードになりうるのか
RSCは段階的に適応可能な技術である一方で、現状の導入に対していくつか障害があると思っています。
それは、
- どこか得たいの知れない複雑な技術として受け取られやすい点（バンドラのサポートが必要である点など）
- 単なる初回リクエスト時のSSRとの区別が難しいため、昔を知っている人ほど既視感と幻滅がある
- フロントエンドを作る人が直接DB等のサーバーサイドリソースにアクセスする処理を書くため、職掌領域にメスが入る
等だと思います。
1と2は実際に触ってみれば解消すると思われるため、自分の作ったハンズオンや採用実績などを通して解消できる問題だと思います。
しかし、3についてはやはり当人のスキルセットに関わることなので、そう簡単にはいかないでしょう。
仮にRSCを利用した開発において、キレイに職掌の分離をするとしたら、
- フロントエンドは「コンポーネント・ユースケースの実装」などの"機能"寄りの部分
- バックエンドは「インフラ構築・認証・DB設計・ドメインモデル設計」などの"基礎"寄りの部分
を担当することになるでしょう。
そうなると明らかにフロントエンドの職掌領域が広がるため、HTTPなどのプロトコルやSQLクエリなどの知識に乏しいエンジニアは手を出しにくいわけです。
だからこそ、フロントエンドとバックエンドがペアプロなどでコンポーネントを一緒に作っていくような努力と、いずれはお互いが一人でEnd-to－Endに作られるようになるための知識移転が必要になっていくわけです。
ですが、そもそもフロントエンドとバックエンドで、チームはおろか、開発会社が分かれているなんてこともざらですし、API設計などに対する知見と経験を持っている人ほど、今うまくいっている"協働の形"を崩すことに抵抗感があると思います。
また、新しいことを学ぶことへの抵抗感については、自分は共感も肯定もできませんが、そうしたものが存在することは明白です。
これらの抵抗に対しては、どれだけ画期的で、生産性を飛躍的に向上させるかを身を以て体験してもらっても、あまり効果が無いのです。
ですが、これは新しい会社にとってのチャンスだと私は思います。
スタートアップ企業などの新しい会社ほど、人員も少なく、End-to-Endな機能開発スキルが求められます。
フロントエンドもバックエンドも担当している人が多いならば、RSCによって面倒なAPI設計および開発がスキップできることは大きなメリットに感じられるはずです。
また、JavaScript（TypeScript）のみで完結するため、新しい人材の育成コストも低く抑えられ、本質的な基礎技術やアーキテクチャの教育に専念できます。
モノリスで小さいアプリケーションを迅速にリリースできれば問題が無い企業にとって、RSCは大きな救いと言えるでしょう。
じゃあ実際どの程度生産性が向上するのか？
それは是非ハンズオン本編で確かめてみてほしいです。
Discussion