インフラ側の人が調べたフロントエンド構成（2023）
バックエンド（よりもさらにインフラより）がメインなのだが、バック側の構成を考えるにしてもフロント側がどうしたいのかを知らないとなぁというところで自分用にまとめます。
フロントエンドUIライブラリ（React vs Vue）
現在はReactが主流なよう。
もちろんVueが採用されるケースもあるとは思うが、2023年時点ではシェアの面でReactが多くなってきている（＝今後のエコシステムなどの発展の面でも期待できる）ことから、強いこだわりが無ければReactを選択でよさそうである。
だいぶ前（2017とかそのくらい？）はVueが優勢だった気がするのでちょっと驚き。
フロントエンドフレームワーク（Next.jsを採用するか？）
調べた限りではNext.jsを採用することが多いと思う。
ただし、Next.jsの機能を使い倒すことが必須か？と言われたらそんなことは無い。
（Next.jsではなくRemixなんてのも最近はあるらしいが、とにかくその類）
Next.jsを利用しない生のReactで作成するSPAは、ランディングページ程度ならよいのかもしれないが、Webアプリケーションと呼べるレベルになるとつらい面がそこそこありそう。
その1つがルーティングで、生のReactはページ遷移に相当するものがURIのpathに反映されない。こうなるとブラウザの戻るがうまく効かなかったり、シェアするときにURIが使えなかったりで不便なのでURIのpathに反映させる必要があるのだが、生のReactだとReact Routerで結構頑張らないといけなくてそこが辛みになる。
その点Next.jsはルーティング周りをディレクトリ配下に配置することでうまいこと扱ってくれるようなので、楽ができる。ただNext.jsはかなり機能的にリッチなので使い倒す！ってくらいに導入すべきかはPJの規模を見てになるんだろうきっと。
以下、Next.js前提で話を進めます。
Next.jsをどうやってホスティングする？
個人的には、簡単にやるならGoogle App EngineやAmplify。ある程度大きくしていくつもりならコンテナ化して各種クラウドのオーケストレーションに任せるかなぁ
尚、↑の選択をするためにNext.jsのISRやSSGや基本利用しない選択になる。
ここはかなり意見が割れそう。だけど、個人的には以下の点を考えてVercelはまずあんまり使いたくないかなぁという。
- 高い（まさにこのZennがVercelから移行した理由がそうだとのこと）
- ベンダロックインがすごい（ISRやSSGが実質Vercelでしか動かない）
- ISRやSSGをちゃんと使いこなすのは結構大変（にみえる）なので、使わない選択も一定合理的に見える
Vercel社の恩恵を受けてNext使ってるのに何がベンダロックインじゃと怒られる気がするが、とは言えどもほぼこれ専用としてベンダロックインされるのは、色々な持続可能性的に出来ればさけたい。
最近はAmplifyとかでISRが部分的に？できたり、そもそもNext.jsからNextなしでイケるような形式のエクスポートもあるみたいだけど不安定な部分がありそうで、ISRとか一部機能をバッサリ捨てて普通にクラウドでホスティングするのがいいのかなぁと思っている。
ISRがあると悩みが増えるところも当然あると思っていて、これごと捨てるというのが全体的には意外と最適なんじゃないか？と思えるというのもある。
CSR/SSR/SSG-ISR のどれがメインになるか？
ホスティング先の制約とNext.jsではピュアなCSRが無いということを考えると、実際のところは全部SSR（で、Next.js前段のCDNとかでキャッシュ）になるんでなかろうか。
これはもう選択肢がほぼないのでこれしかない。
SSRにしておけばSEO的にもそこまで影響は大きくないだろうし。
キャッシュ戦略を考えなくちゃいけないのは特に変わらない。
ユーザ個別コンテンツ（ログイン後のユーザ情報）とかがキャッシュに載ると非常にまずいので、そういうのはSSRでレンダリングせずにuseeffectやらSWRやらでユーザからfetchさせるとちょっとだけ安全だったりするのかな。あとは強いリアルタイム性が必要なものとか。
（でもやっぱりローカルキャッシュに残ってると不具合の素だから気をつけなくちゃいけないのは変わらない、、、）
Spring+テンプレートエンジンとかって駄目なの？
インフラ的には（大体）OKに見える。フロント/ビジネス側がMVVM?でやりたいなら古き良きMVC系のWebフレームワークは単純にフィットしなそうかなぁ。
結局Next.jsでサーバホスティング（SSRっぽいこと含む）するんだったらSpringとかの古き良きMVC系のWebフレームワークからテンプレートエンジン使ってレンダリングしたHTMLを返却する形式でも（インフラ的には）そんなに変わらなくみえる。
ここでそんなに変わらないというのはインフラから見てのスケーリングのしやすさとか、そういう非機能要件寄りの項目について。
ReactとかでStaticに配信できるフロントエンドを作って、動的な値の生成部分はAPIサーバ（Goでもなんでも）に投げるにきれいに分業ができれば、バックエンド側が軽量化されたりしてインフラ側としても差が出てくるけど、ランタイム（Node）必要なサーバスケールさせようとするとスケール時間も結構かかりそうでアクセススパイク辛そうだし、、、という感じでNext使う限りインフラから見るとどっちでもいいよという感覚。（もちろんJavaの場合はVMの面倒見なくちゃいけなかったり在るにはあるだろうが、クリティカルなほどの差は無いかな？）
この辺りはフロント/ビジネス側の要件や、現在のメンバのスキルセット次第なんだろうな。
結局インフラ的には、
CDN -> LB -> (Nginx等) -> Node.js(Next.js) -> (Backend) -> DBの構成になることが多いんじゃなかろうか。
ピュアなReactならほぼ完全にクライアントサイドに負荷を投げる構成がとれて、LB～Nodeのところがもうちょっとスリムになるかもしれない。結局面倒見る対象とかスケーリングで気にしなくちゃいけないところはあんまり変わらないのかなぁ。
参考
Discussion