SPAは間違いだったのか
SPAへの過剰な投資の揺り戻しでMPAに戻りつつある現象が観測出来る
SPAs were a mistake (SPAは間違いだった）
HNで話題になっていた
「ここ10年このゲームは苛立たしかったです。MPAだったものをSPAにして結果的に数倍遅いロードタイムと明らかなバグを生み出してきたプロジェクトを何回も見てきました。それらのうちのプロジェクトのどれもSPAの利点を得ることは結局なかったのです。」（コメント）
To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path.
DeepL訳: 私にとっては、「ほとんどのことは従来のウェブアプリで、いくつかのことはコンポーネント・アズ・ファースト・インテンデッドで」というのが答えのような気がします。最もシンプルなReactの例では、プレゼンテーションとロジックを抽象化した1つのコンポーネントがあるだけです。ステートはそれ自身だけです。SPAとしてWebアプリ全体を扱うわけでもなく、Reduxやプロップドリリングもなく、あくまでHTMLタグとして再利用可能なコンポーネントという考え方です。VueJSとかと同じですね。そこに限定すれば、いい道筋が見えてくる。
ほとんどのことは従来のWebアプリケーションで、部分的に再利用可能なVueやReactといったコンポーネントを埋め込んでいくのが正しいアプローチのように思える。その点Vueは最初から部分利用を前提とした筋の良いアプローチを取っているように思える。
ReactはよりSPAライクな方法論を重視した巨大なSPAモノリスになりがち
SPAがそもそも必要になったのはGmailのようなオフラインを前提としたネットワーク断がアプリケーションの特性となっているようなProductを作ろうとした結果に過ぎない
クライアント-サーバシステムをブラウザで通常より強い分散度で再現しようとした試み
分散システムの法則その１：本当に必要な時を除き分散してはいけない
分散しようとする試みは大抵の場合失敗する。だからその見極めが重要。
ネットワークは魔法の線ではないし、リクエストは届かないということをどれくらい認識出来るか
WWWを最初生み出した時はLAN内で閉じていたものがティム・バーナーズ=リーの想定を超えて世界中で使われるようになった
LANのような（比較的）信頼性の高いネットワークと比べてWANのなんと頼りないことか
我々は分散することで必要となる努力の量を常に想定より低く見積もってしまいがち
分散には覚悟が必要
似たようなコメントがあった「SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.」
オフラインサポートが必要な場合を除いていい選択だとは正直思えない
本当にSPAが良いものならSPAの走りのGoogleが全てのサービスをSPAで作るだろうが、利用はよく考えられて制限して使用されている。どちらかというとMPAが多い印象
SPA辞めました→MPAにしましたという事例
AmebaNews
Astro, RemixといったMPAを意識した実装等
Alpine.jsといった軽量なコンポーネント指向ライブラリ
VueやReactといった基本はSPAであることを目標としたライブラリは得てして過剰設計になりがちなことに対する反省
サービス全てを大統一ライブラリにすることに対する反省
マイクロフロントエンド
フロントエンドの各コンポーネントレベルでも必要とされるライブラリは変わってくる
ここはVue, ここはReact, ここはSvelte, ここはAlpine、ここはWebアプリといったようにコンポーネント粒度に応じたものを利用出来るべき
根本的にはDOMの各部分要素はComponentとしてライブラリの影響範囲も閉じ込められるので可能
SPA vs MPAの議論
論点としてこの対立軸になるとあまり有益な結論を出せない気はしている
アーキテクチャの特性として求められるものは場合によってはSPAでもあるしMPAでもあるしSPAとMPAのハイブリッドな特性が求められる場合もある
ただそれでもMPAに揺り戻している観測が出来るのは多くの人間がある程度SPAに慣れ親しんだ結果その反省がカウンターとして現れているのだと思っている
具体的にはSPAである必要のないサイトをSPAにすることによって分散する必要のない場面において分散アーキテクチャになること
開発者体験を優先し一貫性を犠牲にして初期化の遅いSPAにすることで逆にユーザ体験が下がっている
結局ネットワークは光の速さを超えられないしブラウザがJSを初期化する速度には物理的限界がある
Webアプリでレンダリングして返す、もしくはHTMLをCDNにキャッシュするのが最速でユーザ体験として最高
SPAにする利点としてはフロントエンド専門のチームなどに分割しやすいというのはあるがそれも大きな利点でもない
結局分散した先に別のモノリスが出来るだけで本質的ではない（当たり前だが分割するというのが常に適切なアーキテクチャDecisionになるわけではない）
ユーザとしては裏のチームがどうなっていようと関係ない
初期化において明確にJSは遅いという問題を抱えている。大きいバンドルサイズ、Hydration、APIコール後に最初のMeaningful Paint等
アプリケーションライクなものには向いているテクニックだが、長い期間に渡ってのコンテキストが重視されるようなものはMPAの方が向いている
SPAは最小のマイクロサービス
古のクラサバへの回帰
厳密に言えばWeb自体分散システムではあるけど
クライアントに状態を持たせサーバと分離することから不幸が始まる
楽園追放
突き詰めて分散システムというのを考えると本当に悪魔のように難しい
分散システムの難しさを分かっていますか？ということを改めて分散する前に問わなければならない
分散システムを舐めてはいけない（戒め）
まずアーキテクチャとして粗結合にしたことで、本当にチーム分散出来ていますか？ということを自問しなければいけない
ただアーキテクチャとして粗結合にして組織が密になっていればただ分散したモノリスという最悪のアーキテクチャが出来るだけ
それこそ別組織レベルでお互いに共通するものを一切無いシェアードナッシングなアーキテクチャでしか本当の意味で分離したことにはならない
人材の採用から使う言語、人種、チームの状況までお互いからはブラックボックスになり自己完結するといった
最終的な目標がユーザへ価値を届けるということだけを見据えるとAmazonのような巨大な組織をスケールさせるために必要な措置だった
結果としては成功しているが、中でそれを実行しているチームは血反吐を吐くような思いでやっている
見かけ上フロントエンド、サーバサイドとチームを分けたところでこのAPIはこうしましょうのような密な結合が発生すると分散したモノリスになる
なら最初から密に結合したモノリスで行き、モノリスを突き詰めること
判断を早く下しすぎ、間違ったアーキテクチャDecisionをしないこと
ただ想定はしておく。v1.0, v2.0といった形でスケールを見越してロードマップを作る
モノリスを突き詰めずにモノリス＝悪のような安易な結論に飛びつかないこと
モノリスを究めて、もうどうしようもないという結論に至ったらやっと分散を検討するぐらいでちょうどいい
AWSでさえ従業員数が1万程度になってやっと始めた
ちゃんとそのモノリス、究めてますか？
早すぎる最適化、金メッキ…不確実性へ対処しようとした結果生じる必要なアーキテクチャ特性以上のものを持つアーキテクチャ
特定のクライアントを想定したレスポンス、特定のUIを想定したAPI…
間にBFFを入れれば解決するとかそういう問題でもない
BFF層で新たな結合が発生するだけ
結局どこまで行っても組織論