2025年時点のWebアプリ技術選定
言語とフレームワーク
Section titled “言語とフレームワーク”今からはじめるならReact Server Componentsは無視できない。2024年時点ではReactフレームワークを使わないと言っていたが、独自でReact Server Componentsを使うためにはビルド時に追加のライブラリが必要になるようだった。そうだとするなら、あまり普及していないライブラリよりも広く普及しているReactフレームワークを採用した方が生き残りやすいだろうと思う。SPAを作成するためのフロントエンドフレームワークのなかでNext.jsは巨大で複雑と聞いているので、比較してシンプルなReact Router v7を採用。
言語はTypeScript一択だからRoute Module Type Safetyも行っておく。
もちろん裏側は素朴なHTTPリクエストだから、Next.jsのServer Actionの正体は何なのかの文中で書いたAPIを実装すればGoでもサーバーコンポーネントの実装は可能だろうが、面倒なだけで嬉しさは無い。
React Server Componentsの世界ではサーバサイドでTypeScriptが動作する必要があるけれども、バックエンドまで全てをTypeScriptで書く気はないので、BFFを用意して防波堤とする。レイヤーが増えるので複雑さは上がるのだが、仮にバックエンドがマイクロサービスとなった場合、複数のマイクロサービスから取得したデータを統合してフロントエンドに返すためにも利用できる。
クリーンアーキテクチャはなぜフロントエンドに合わないのかでは
フロントエンドは全部置き換えられるから、ちゃんと作ったとしても結局は書き捨てに近い … バックエンドで書かれたコードは10年前のコードであっても基礎に近いほど当時と同じコードで動いています。しかし、フロントエンドで10年前に書かれたコードが今もあるでしょうか
と書かれている。書き捨ては言い過ぎだとしても、現代はReactが支配的だけど、周辺のツールやライブラリは入れ替わりが激しいし、フレームワークの規模で入れ替えるとなったら確かに全部捨てることになる。画面に応じて入れ替わるフロントエンドと、大きくは変わらないバックエンドで境界を設けておくことは間違いではない、と思う。
バックエンドはGoで実装する。BFFとバックエンド間の通信プロトコルはフロントエンドとバックエンド間の技術選定に挙げたが、
- 型を自動生成できる
- カスタムオプションでバリデーションも利用できる
- Domain Modeling Made Functionalでいう「型によるドキュメント」を実現できる
- GraphQLと比べてパフォーマンスを読みやすい
といった特徴があるのでConnect(gRPC)がいいと思う。
ホスティング
Section titled “ホスティング”バックエンドはGoogle CloudのCloud Runで実行する。App Engineでもいいのだけど、コンテナイメージを使ったデプロイ等はCloud Runの方が便利だろう。
フロントエンドとBFFはCloudflare Workerに置く。BFFとバックエンドの距離が近い方がパフォーマンスの面で有利なので、Cloud Runで実行した方がいいのかもしれないが、これは単にCloudflareを試してみたいから。必要ならR2やD1でキャッシュすればいい。