【要約】ＡＷＳで整理する、フロントエンドの知識地図 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
クラウドエンジニアがフロントエンド領域へ進出する際、膨大な技術の選択肢を整理できず、適切な選定が困難になる問題がある。具体的には以下の課題に直面する。
- ・技術の選択肢が多すぎて、各フレームワークの差異が理解しにくい。
- ・フロントエンド技術と、デプロイ先のインフラ構成との相関が見えにくい。
- ・SEO、UX、コスト、運用負荷といったトレードオフの判断基準が不明確である。
// Approach
本記事では、デプロイ先のインフラ構成とHTMLの生成場所を軸とした分類手法を採用している。技術を以下のステップで構造化して整理している。
- ・デプロイ先を「FE/BE分離型」「SSR/MPA型」「SaaS」の3パターンに分類。
- ・レンダリング方式を「SPA」「SSG」「SSR」「MPA」に整理。
- ・各フレームワーク（Next.js, Laravel, Spring Boot等）をこれらの軸にマッピング。
- ・SaaSと自前インフラの境界線を、Headless API連携の観点から定義。
// Result
開発者は、プロジェクトの要件に基づき最適な技術スタックを選択できる指針を得られる。これにより以下の成果が期待できる。
- ・インフラ設計とフロントエンド選定の不整合を防止できる。
- ・SaaS活用とフルスクラッチ開発の境界線が明確になる。
- ・SEOやUX、運用コストのトレードオフを考慮した、合理的な判断が可能になる。
Senior Engineer Insight
> 技術選定の前に「SaaSやマネージドサービスで要件を満たせないか」を問う姿勢は、実戦におけるアーキテクトの責務である。単なるフレームワークの比較に留まらず、インフラ管理コストや運用負荷、SaaSとの境界線にまで踏み込んでいる点が極めて実戦的だ。過剰なフルスクラッチ開発を避け、顧客にとって最適なコスト・速度のバランスを実現するための、優れた意思決定フレームワークといえる。