React Server Components
サーバーでのみ動く
サーバーサイドのデータに直でアクセスできる
よりシンプルなプログラミングモデル
cliant / serverをシームレスに拡張する
clientに送らないといけないコードをかなり減らすことができる
Suspenseを使って実装されている
Next.jsがαサポートしている
PHPやRailsのSSR（昔からあるやつ）はDBに直アクセスしてデータを埋め込んだHTMLを素早く表示できた
SSRは初回のHTML構築でこれができるが、それ以後はクライアントがAPIを叩いてデータフェッチする
RSCはデータフェッチするときにサーバーサイドで処理してtreeをmergeする
SSRを置換するものではない
SSR
初期のHTMLをサーバーサイドで行う
その後はクライアントのJSで処理
つまり全てのJSがクライアントに送出される
React Server Components
レンダリングされるまでクライアントに送られない
DBからデータをフェッチするコンポーネント
再レンダリングが必要になったらre-fetch後に既存のcomponent treeにmergeされる
>
クライアントでの処理が重いものとかに使える
これによって、renderをclient/serverどちらで行うかを、コンポーネント単位で決められるようになった
開発者が意識せずともブラウザでダウンロード・実行されるJSが減る
>React Server Components を使う限り、もはや SSR or CSR（SPA）という議論は意味を無くします。両方のいいところどりができて、面倒な部分はライブラリやフレームワークが対処してくれて、しかもファイル名を変えるだけで実現でき共存するため、利用者が意識をすることもなくなるでしょう
>たとえば、多くのウェブサービスでは、認証APIを叩いて、ユーザー情報APIを叩いて、ほげほげAPIを叩いてというふうに、複数の API を叩くことになります。ところがウェブブラウザは1つのサイトに対して最大同時アクセス数は極めて小さな数字に制限されています（制限されていないとDoSになってしまうため）。
> 認証APIはさすがにどうやっても待たないといけないでしょう。そういったものはどうしようもありませんが、それ以外のリソースは同時にアクセスしても良いと思いませんか？
> React Server Components では API 呼び出しをサーバーコンポーネント上に記述することで、ウェブブラウザとは異なり、同時アクセスはサーバーのリソースが許す限り並列に行えます。そして、それらが完了してるかどうか？の面倒な処理も React suspenseの仕組みに乗っかることができます。