React Server Component メモ
takewellとりあえずことの発端はこちら
takewellみんな大好き mizchi さんの見解をさらに整理
やや硬く感じるがつまりは以下のように要約できそう。
React Server Component は React コンポーネントをサーバー(ただし Node.js)から API のように非同期読み込みすることを可能にする react の機能である。
目的についても肥大なサイズのライブラリをユーザーに送らない点、server client でのシームレスなインテグレーション(開発者視点では)というものを点の狙いがあるのではと言われている。
tl;dr
サーバーでのレンダリング結果を JSON シリアライズして、クライアントから要求できる。サーバー側での React Element の組み立ての過程にサーバー(Node.js)の API が使えるので、都度 API を実装する必要なく、RPC の中で隠蔽できる。一種の Isomorphism (クライアント・サーバー同型写像)。
これはつまり、サーバーで実行、更新される非同期コンポーネントであり、比較対象は Rails Hotwire, Phoenix LiveView の非同期 View などになると思われる。
React Server Component の目的
そもそも手段は一つだが、目的が二つ混ざっているので、これを整理する。
ビルドサイズを重くなってしまうライブラリをサーバーサイドで実行して結果だけ返す。例えば marked や prettier、babel など
RPC によって Client と Server で API の呼び出しを自然に隠蔽する Isomorpish を実現する
takewellReact Server Component (以降 RSC) のすごい点は究極的には 1つ。昨今肥大化気味の node_modules のサイズ削減のための解決策としてかなり有効。なんせ bundle size zero。加えて、ページ遷移をする際もコンポーネントそのものを非同期に読み込むことができるので、SSR と異なり SPA (ページの再読み込みなし)を維持したまま実行させることができる。(ユーザーにステートを持たせた操作を継続してもらえる)
さらに雑にいうとこれですごい爆速な SPA が作れるようになる。しかもライブラリのサイズを気にする必要がなくなってみんなハッピー。(実行が遅いともちろんダメだがつまり、サイズの問題で導入を見送ってきたライブラリもカジュアルに導入することができそう)
ちなみにバックエンドへのフルアクセスができる点がメリットにあげられる場合があるが、それは node.js で実行されるのだから当たり前ではないだろうか... とは思う react-pg react-fs というライブラリが作られる予定? のようだがこれはただのラッパー。 しかし、これまで facebook はサーバーで react を実行する手段を実装してこなかったのでその点では nodejs サイドにも fb がよりコミットするかもなので期待。(例えば facebook 様が node.js で動く最強の ORM などのライブラリをこぞって作ってくれると嬉しい(願望))
しかし、この RSC だが 背景となる知識あやふやだと、混乱する可能性がある。
例えば SSR とは何が違うのか？という点だ。言ってしまえば SPA と SSR のいいとこ取りなのだけど、説明は以下の qiita のポストで図解されていてお勧め。
あと RFC にも FAQ も丁寧に用意されており。誤解して欲しくない旨が一通り言及されている。
最後に考えらえるデメリット... それは node.js さんの面倒を見ないといけない点...(node.js のデメリット) IO ヘビーな処理は得意だが シングルスレッドなので マルチスレッドとかでやりたい CPU ヘビーな処理は苦手、あと一つのプロセスが落ちると全部落ちるのでエラーハンドリングはシビアとか、クライアントサイドの JS なら知見はそれなりに多い人は多いが、nodejs の運用となると別なので採用及び、学習の難易度はそれなりにありそう。
しかし、重い処理はマイクロサービス的な観点に立って別の言語で実装し、それを呼び出したり アグリゲーションするのに薄く node.js を用いるというのであればワークするかもしれない。
takewellより大局的感想としてはフロントエンド領域がどんどんサーバーをフィールドとしていくな... と感じた
これまでブラウザで動く JS を主なフィールドとしていたが、今後 node サーバーの面倒も見ていく必要が出てきそう。
wasm が CDN で動くとかいう世界になるとするとさらに RSC を CDN で配信するとかいう状態にもなりかねない。そうなると 爆速 SPA が実現されクラアントアプリと遜色ない UX が実現できるようになればモバイル web への揺り戻しも起きそうな直感も生まれる。(まあこの部分は希望的観測であることは否めない)
これまで
browser <=> api server
RSC 以後
browser <=> front server (e.g. next.js)(ここは nodejs でないとそんなメリットがない) <=> api (micro service や sass api)