- サーバーコンポーネントとサーバーアクションを追加したReactは、フルスタックフレームワークへと進化しつつある
2010年、フレームワーク戦争の始まり
- 2010年にBackbone、Knockout、Emberで始まったフレームワーク戦争には、AngularとReactがすぐに続いたが、その結末を予測できた人はいなかった
- 長い間、クライアントサイドレンダリング（CSR）のJavaScriptアプリケーションが支配的だった
- こうしたアプリケーションはシングルページアプリケーション（SPA）とも呼ばれ、一般的に小さなHTMLファイルと大きなJavaScriptファイルで構成されていた
- コード分割が導入されるまでは、そうだった
フロントエンドとバックエンドの分離
- この期間、フロントエンド開発はさまざまなJavaScriptフレームワークやライブラリに支配されていた
- バックエンドは通常、特定の言語に縛られず、RESTがAPI通信の標準になっていた
- 私はフリーランスのWeb開発者として、主に.NET、Java、Python、PHPのバックエンドと仕事をしてきた
- TypeScript/JavaScriptをバックエンドで見かけたのは、グリーンフィールドプロジェクトか、バックエンドを自分でコントロールできる小規模プロジェクトだけだった
- しかし、フルスタックReactの台頭によって、これは変わるかもしれない
- 2010年から2020年までの時期に対する開発者の認識が、キャリアを始めた時期によって異なるのは興味深い
- 2010年以前に始めた開発者はサーバーサイドレンダリング（SSR）の環境にいたため、最近のサーバーサイド技術への回帰にもより自然に適応しているように見える
- 一方で、多くのほかの人々は、ほぼ10年間、REST APIを使ったクライアントサイドレンダリング（CSR）アプリケーションでのみ作業してきた
- そして今、彼らは新しいフルスタックReactの世界をどう受け止めればよいのかわからずにいる
TypeScriptが業界標準として登場
- ここ数年で、TypeScriptは業界標準として台頭した
- TypeScriptはフロントエンド開発者に、型付けされた強力なプログラミング言語を提供した
- 開発者がTypeScriptを受け入れるにつれ、もはや後戻りできない段階に達した
- コードの小さな変化が、個人にも業界全体にも大きな影響を与えうるというのは興味深い
TypeScriptとRESTの難しさ
- TypeScriptがRESTにもたらした影響には、その場しのぎの解決策が多い
- OpenAPI（旧Swagger）はREST APIのドキュメント化のために存在していたが、今では主に型付きAPIインターフェースを生成するために使われている
- クライアント・サーバーアーキテクチャで完全な型インターフェースを作れるにもかかわらず、最初からそれを正しく実装できないプロジェクトは多い
- 個人的なメモ: "OpenAPIベースのアーキテクチャで良い経験をした開発者もいるだろうが、残念ながら筆者はそうではない"
TypeScriptが空気を変えた
- TypeScriptがここでどのように空気を変えたのかを見るのはかなり興味深い
- 一方では、REST（ドキュメント目的のOpenAPI）を使う型なしのSPAは「問題ない」ように見えていた
- しかし、TypeScriptが標準となり規範と見なされるようになると、生成された型インターフェースは、フロントエンドのコードベースにおけるより高い基準に慣れた開発者にとって扱いにくいものになった
- 生成された型インターフェースの欠点は明確だ:
- 常に生成ステップが含まれる
- 生成された出力が複雑である
- 初期設定によっては生成されたコードが常に正しいとは限らない
RPCとtRPCの登場
- RPCは新しい概念ではないが、tRPCのおかげでReactエコシステムで人気を集めた
- 8万行のコード規模のアプリケーションで、6か月間ソロ開発者として働いた経験から言えば、バックエンドの関数を呼び出してデータを読み書きすることは、まるで啓示のようだった
- TypeScriptを使うスタックの両側で、これ以上に生産的だと感じたことはなかった
- 個人的には、数年前に（生成された）型付きGraphQLアーキテクチャでだけ、同じくらい生産的だと感じたことがあった
- 2023年の1年を通して、tRPCより優れたものは想像できなかった
- バックエンドの関数を呼び出してデータを読み書きすることは、革命的に感じられた
- だが、それが自分に必要なすべてだったのだろうか？ そうではなかった
Server ComponentsとServer Actionsの革新
- 私にとって本当のブレークスルーは、2024年にServer ComponentsとServer Actionsからもたらされた
- これらは単にサーバーを呼び出すだけでなく、向こう側でコードを実装して実行できるようにすることで、サーバーとの隔たりを埋める
- Server Componentsは、Reactコンポーネントをサーバー上で実行できるようにし、JSXとしてUIを返す前にデータソース（たとえばデータベース）へ直接アクセスできるようにする
- Server Actionsは、内部でHTTP APIエンドポイントを生成し、リモートプロシージャコールのように関数を実行・呼び出しできる
- Server ComponentsとServer Actionsは、Reactをフルスタックフレームワークへと変貌させる
- フロントエンドをフルスタック環境へ移行する、刺激的な時期だ
ReactのServer ComponentsとServer Actionsサポート
- React自体は、Server ComponentsとServer Actionsのための基本要素と仕様だけを提供している
- Reactの上に構築されたメタフレームワークは、クライアントとサーバーの間のディレクティブを解釈するバンドラーとして、そのギャップを埋めることができる
- Next.jsは、Server ComponentsとServer Actionsの実装を先導している
- Next.jsは以前からサーバーサイドレンダリング（SSR）をサポートしていたが、今ではServer ComponentsとServer Actionsを通じて、開発者はデータベースやメッセージキューのようなサーバー側リソースにアクセスできる
フルスタック開発の始まり
- Reactを使ったフルスタック開発は、まだ始まったばかりの段階だ
- 開発者がServer ComponentsとServer Actionsを通じてデータベースに直接アクセスし始めるにつれ、単純なCRUDアプリケーションを超える複雑さを飼いならしていく過程があるだろう
- 徹底した学習を通じて、フロントエンド開発者は、レイヤー、設計パターン、ベストプラクティスを使ったバックエンドアーキテクチャ実装をやがて習得するだろう
- 正直に言えば、Reactコンポーネントの中でORM関数呼び出しを見たい人など誰もいないからだ
パラダイムシフトへの期待
- 私はこのパラダイムシフトに大いに期待している
- React開発者が、UIからデータベースまで垂直統合された機能を実装する新しい時代に備えることになるだろう
8件のコメント
フルスタックは全部やってくれたじゃん
アプリ開発のように他言語との互換性を考えるなら、tRPCはあまり良い選択ではない気がします。😅
私はGraphQLが最善だと思います。
nextjs server actionは、開発者が制御できないランダムなAPIエンドポイントをpublicに露出してしまう問題があり、かなり脆弱な部分だと思います。
おっしゃっているのがどの脆弱性なのか、教えていただけますか？検索すると SSRF 脆弱性というものが出てくるのですが、それで合っているのかよく分からなくて。ちょうど Next.js を勉強しているところなので、気になってお聞きしました。
そもそもSPAを推していた人たちの意図は何だったのでしょうか？ jQueryでDOM操作をしていた時代よりはるかに良くなったのは確かですが、バックエンド／フロントエンドの設計や開発に必要な概念がなくなったわけではなく、場所が移動しただけのように見えます。ルーティングだけを見ても、サーバーからクライアントへ移したかと思えば、サーバーサイドレンダリングの流行のせいで再びサーバーに戻そうとしています。
3年後でも、はたしてコーディングスクールや講座でSPAスタイルのReactを教えているのか疑問です
ページ移動のスムーズさが最大の長所ではなかったでしょうか（当時は）
元の記事の最後は、著者が開設予定のフルスタックWeb開発教育課程 The Road to Next の宣伝で締めくくられます ^^;