新規サービス立ち上げるときのスキルセットって、技術が進歩するに従って安牌構成がアップデートされていくと思うけど、現時点ではこんな感じで認識している。

• internalなアプリ / UI不要 => Laravel / RailsとかのMVCで作成。シンプルなCRUDのUIだけに留める。使いやすいUIをカスタマイズしようとか思わない。モダンなフロントエンドライブラリは基本使わない。
• C向けアプリ / 外部向けアプリ / レスポンシブ対応 => 人員がいるならモダンフロントエンド + MVCのAPIサーバーで構成。SPAはFull CSRでも良いしSSG / SSRでも良い。Full CSRのほうがアーキテクチャがシンプルだけど、Next / NuxtとかのFWによる開発体験も捨てがたい。FWを選ぶと結局SSG / SSRもオマケでついてくる。将来BFFとかしたいのなら最初からFWにしておいたほうが良い。人員がいなければ、初期のうちはNext / NuxtのSSRに付属しているAPI機能を使っても良いかも。

動的なアプリはDBが一番寿命が長いので、DBを基準に技術選定するのが基本だと思う。そうなるとMVC FW一択なはずだけど、UIがちょっとややこしくなるとReactとかがやっぱり欲しくなる。生HTML / CSS / jQueryでも組めなくはないけど、CSSをちゃんと管理するには最低限のルールが必要だし（BEMとか）jQueryでゴリゴリ組んだUIは作ったひとしかメンテナンスできなくなりがち。モダンフロントエンドを選ぶと人員がーとか保守性がーとか言われがちだし、実際そうだとは思うけど、結局同じ人が長期メンテナンスできない環境では保守性は著しく下がるし、一定水準のUIが求められるならReactとかがやっぱりほしい。そうなるとSPA + APIサーバーという構成に帰着するけど、正直これもどうなのと思うことが多い。APIを疎結合にすることで腐敗防止層にするという話だけど、たった1つのアプリのために疎結合なインターフェースを設けてそこの設計をするコストが馬鹿にならない。あと。APIサーバーが腐敗するような環境だと、APIもわりと腐敗しがちだと思う。APIを設けることで疎結合というのはかなり長期的な目線に立った話なので、長期目線の運用が前提でかつ人員が豊富な場合に限る気がする。フロントエンド or バックエンドサーバーを個別にフルリプレイスする目処が立った場合にこの構成が初めてありがたみを感じる気がする。
となると、人員が足りない初期の頃はMVC単独が無難な気がしてくるけど、Next / Nuxtの進化でフロントエンド向けFWでバックエンド込みのPOCを作るというのが視野に入ってきた。
Next / NuxtのAPI機能を使えば、テーブル数が少ないうちはNext / Nuxtでもバックエンド組めると思うし、ServerComponentの進化で、API自体を意識して作らなくて良くなって来ている。一方で反面密結合の懸念もあるけど。
でも1つのアプリの中で密結合であることにどこまでリスクがあるか改めて考えてみても良い気がする。密結合のリスクを過大評価して、疎結合の実装コストを過小評価しがちなのがSPA + APIの最近のオーソドックスな技術選定なんじゃなかったかな。MVCフレームワークだけで十分にPOCを作れるという意見もあるし、密結合でも良いのでコストを下げるという視点に螺旋で戻ってきたようにも見える。
Laravel / RailsなどのMVCフレームワークでももちろんUIは組めるけど、どうしてもUIの表現力は落ちる。
Next / NuxtなどのフロントエンドフレームワークでもDB / バックエンドは組めるけど、十分な実績がないし機能も足りていないところが多い。
けどどちらの種類のFWでもアプリを組むことはできて、それがDB寄りなのかUI寄りなのかの違いしかなくなってきている。
フロントエンド + バックエンドで構成を分けるのではなくて、要件に応じてどちらかのFW一本に絞ってサクサク開発を進めるというコスト削減の目線もあると思う。