データフェッチの変遷

バケツリレー時代（距離：３）

データベース＞親＞子＞孫（３）

ReactのClass時代には、
Reactが表示するデータを取得するのはデータベースからデータを取得した後は・・
最初はバケツリレーで
親コンポーネントが受け取り、
子コンポーネントが受け取り、
孫コンポーネントが受け取りました。
これはネストが深くなるほど複雑化していき、嫌われていたようです。

※これらのイメージは、あくまでも筆者の主観です。

Reduxの登場（距離：２）

データベース＞グローバルストア＞孫（２）
グローバルデータストアという考えが取り入れられ、
孫コンポーネントはグローバルデータストアからデータを取得しました。
しかし、Reduxの最初期は設定が複雑で一部嫌われていたようです、
その後、Redux ToolKit (RTK)の登場によりReduxの冗長性が排除され簡素化されていきました。

Hooks時代の到来（距離：２）

データベース＞親＞孫（２）

Reactの16.8からHooksが登場します。
Hooksを利用することで親コンポーネントから孫コンポーネントへ直接データを渡すことが出来るようになりました。

State管理群雄割拠の時代に突入 fetch関数（距離：１）

Reduxの1強時代が終わり、Recoil, SWR, TanStack Query(React Query),
Jotai, Zustand等が出現してきました。

Reactにfetch関数が呼び出せるようになりました、これでAPIを通してデータベースから直接データが取得できるようになりました。（クライアント側からです。）

親コンポーネントを飛び越えてデータベースにAPIを経由して直接データを取得できるようになりました。

ハイドレーションとは？

ハイドレーションとは合体という意味だと考えています。
クライアント側でサーバーから送られてきたHTMLファイルとJavascriptファイルを合わせる作業になります。

クライアント側でJavascriptがデータフェッチを行い、そのデータをHTMLファイルに入力して一つのコンポーネントを作成します。

サーバーコンポーネントの出現！（距離：０）

データベース＝サーバーコンポーネント（０）

コンポーネントの最初のイメージは、ブラウザ画面の一部をレゴブロックのように組み合わせる１つのパーツというイメージでした。
それをサーバーコンポーネント？？と言われてもピンときませんでしたが・・・

サーバーコンポーネントとは？

シンプルに言うと、サーバー側でデータを取得してコンポーネントを完成させてから、その完成部品をクライアントに送る方式になります。

Next13 ServerComponents ＆ ClientComponents時代がもうすぐ到来します。
※appディレクトリは現在ベータバージョン（2022年12月24日）

サーバー側でデータベースからデータを取得できるのなら最初から取得して、不要なデータをクライアント側に送ることをせず軽量化することでより高速になることを目的としています。
もちろんクライアント側からデータを取得する従来の方式も使えます。

感想

Next13 ServerComponentsとClientComponentsをみるに、
クライアント側という事を意思表示するためにファイルの冒頭に
"use client"
を書くようになっているので、Next13からはフロントエンドではなく、バックエンドの役割を強く意識するように作られていくようです。
BFF（Backends For Frontends）よりも、もっとサーバー寄りなイメージになっていくのではないでしょうか。

前回記事

Web開発ツールスター数調査（テストツール、状態管理、GraphQL） - Qiita
https://qiita.com/masakinihirota/items/c963f4d13b40bfb198eb

おまけ

tRPC時代へ（距離：１）

データベース＞孫（１）

tRPCはTypescriptを利用して、API通信を意識せずに、 普通の関数のようにデータベースからデータを取得できます。
その際にデータ検査にzodライブラリを使用します。

※これらの図はFigmaで作成しました。