Webアプリの種別（SPA/MPA, CSR/SSR）とAWSとGCPのホスティングサービス比較（育休0日目〜技術選定〜）

この記事はなに

こんにちは、kazです。育休取得にあたりWebアプリを作ることにしました。

今回は、どんなアプリにするかを決めるために、Webアプリの種類を比較しました。
また、GCPで実現するにはどんなサービス構成になるのかを知るために、ホスティングサービスをAWSとGCPで比較しました。

どんなWebアプリにするか

Webアプリの種別

会社でも使用している、GenUのようなものを目指したいと考えました。特徴としては、

• /chat や /agent で各機能のページに遷移する
• インストールしてネイティブアプリのように使うことができる
• 描画にはLambdaを使っているのでサーバレスで維持費がかからない
• 簡単なコマンドでデプロイができる

下記の技術を備えれば、上記要件が実現できるようです。

• SPA（シングルページアプリケーション）⇒ スムーズな操作性を提供可能
• CSR（クライアントサイドレンダリング）⇒ サーバを必要としない。かつLambda関数はデータを返すだけ（HTML要素を返さない）
• PWA（プログレッシブWebアプリケーション）⇒ ホーム画面に追加してアプリのように利用可能

GenUのようなアプリを目指すので、SPA+CSRに、PWAを組み合わせることにしました。

各種別について、知らなかったので調べてまとめました。

SPA (Single Page Application) と MPA (Multi Page Application)

特徴	SPA (Single Page Application)	MPA (Multi Page Application)
定義	単一のHTMLページで構成され、JSでコンテンツを動的に更新。	ページ遷移ごとにサーバーから新しいHTMLを読み込み、再描画。
UX	JavaScriptがDOMを部分的に更新するため、非常にスムーズで高速 (ネイティブアプリ的)。	ページ全体が再ロードされるため、画面のちらつきや遅延が発生。
SEO	検索エンジンがJavaScriptを網羅できないため不利。SSR/SSGと組み合わせることで改善。	各ページが固有のURLとHTMLを持つため、非常に優れている。
開発の複雑さ	モダンなJSフレームワーク (React, Vue, Angular) の知識が必要。状態管理、ルーティングの複雑さ。	各ページが独立しており、比較的シンプル。サーバーサイド言語が中心。
モバイルアプリ連携	PWAとしてホーム画面に追加可能。	一般的なブラウザ表示。
URLとナビゲーション	JSでURLを制御 (HTML5 History API)。ブラウザの戻る/進むボタン対応が必要。	各ページが固有のURLを持ち、ブラウザの戻る/進むボタンは期待通りに動作。
適した用途	管理画面、SNS、Webメール、オンラインツール、複雑なWebアプリケーション。	ブログ、ニュースサイト、企業サイト、ECサイト（商品ページなどSEO重視）。

CSR (Client-Side Rendering) と SSR (Server-Side Rendering) 比較表

特徴	CSR (Client-Side Rendering)	SSR (Server-Side Rendering)
定義	サーバーは最小限のHTMLとJavaScriptを送信。ブラウザでJSがHTMLを構築・レンダリング。	サーバーが完成したHTMLを構築し、ブラウザに送信。ブラウザはそれを表示。
初期表示までの流れ	1. HTML受信 (空または骨組み) 2. JSダウンロード・実行 3. コンテンツ描画	1. 完成HTML受信 2. コンテンツ描画 3. JSダウンロード・実行
初回表示速度	JSダウンロード・実行に時間がかかり、遅い傾向。	サーバーから完全なHTMLが届くため、速い。
インタラクティブ開始	コンテンツが表示されれば、比較的早くインタラクティブになる。	コンテンツはすぐに表示されるが、JSの実行完了まで操作できない時間が生じる可能性。
ページ遷移	初回ロード後は、JSで動的に部分更新するため、非常にスムーズで高速。	ページ遷移ごとにサーバーから新しいHTMLを再取得するため、長くなる傾向。
SEO	不利。クローラーが完全にJSを処理できないリスク。	サーバーから完全にレンダリングされたHTMLが提供されるため、非常に優れている。
開発の複雑さ	クライアントサイドの開発に集中できるため比較的シンプル。	サーバーサイドのレンダリングロジック、データフェッチ、ハイドレーションの考慮が必要なため、複雑になる傾向。
開発環境	ホットリロードなど、高速な開発サイクル。	サーバーとクライアントの両方を考慮する必要があり、ビルド時間が長くなることも。
主な用途	ログイン後のダッシュボード、管理画面、複雑なWebアプリケーション (高度なインタラクティブ性)。	ブログ、ニュースサイト、ECサイトの商品ページ、Webサイト（SEOが重要）。

AWSとGCP

こちらの記事 を参考にすると、ピヨログで記録したデータをエクスポートするのに、「MacroDroid」というアプリで自動で定期実行していました。

ピヨログアプリからは記録をテキストとしてエクスポートできるのですが、エクスポート先として、GoogleDriveを利用するのが良さそうでした。
そうすると、エクスポートしたテキスト情報を加工するのに、GoogleCloudが良いのではと考えました。

AWSで言うところのS3+CloudFront+API Gateway+Lambdaは、
GCPだと何のサービスに相当するのかを知るために比較を行いました。

GCPだとFirebaseの中でいくつか組み合わせることで実現できるようです。
自信を持って、Firebaseで進めることにしました。

AWS と GCP ホスティングサービス比較表

項目	AWS (Amazon Web Services)	GCP (Google Cloud
静的ウェブサイト	Amazon S3 + Amazon CloudFront	Cloud Storage + Cloud CDN / Firebase Hosting
	- S3: 静的ファイルを直接ホスト可能。 - CloudFront: S3のコンテンツを高速配信。	- Cloud Storage: オブジェクトストレージで、静的ファイルを直接ホスト可能。 - Cloud CDN: Cloud Storageのコンテンツを高速配信。 - Firebase Hosting: 静的サイトやSPAに特化。CDN、SSL、カスタムドメイン、PWA機能が標準。
コンテナベース	Amazon ECS / EKS / Fargate	Google Kubernetes Engine (GKE) / Cloud Run / App Engine Flex
	- ECS: コンテナサービス。 - EKS: Kubernetesサービス。 - Fargate: サーバーレスコンテナ。インフラ管理不要。 - Lightsail: 低コストでシンプルな仮想サーバー/コンテナ環境。	- GKE: Kubernetesサービス。Kubernetesのオリジン。 - Cloud Run: HTTPリクエストに応じて自動スケールするサーバーレスコンテナ。リクエストがないときはゼロスケール可能。 - App Engine Flex: カスタムランタイムのPaaS。
PaaS (プラットフォームとしてのサービス)	AWS Elastic Beanstalk	App Engine Standard / Flexible
	- コードをデプロイするだけで、環境構築、デプロイ、スケーリング、ロードバランシングを自動化。 - 様々な言語 (Java, Node.js, Python, PHP, Ruby, .NET, Go, Docker) をサポート。	- Standard: 特定の言語/バージョンに特化し、コールドスタートが速く、無料枠が豊富。 - Flexible: Dockerコンテナベースで、より柔軟な言語/ランタイムをサポート。コールドスタートはStandardより遅いが、より強力なリソース。
サーバーレス（関数）	AWS Lambda	Firebase Functions/Cloud Functions
	- API Gatewayと組み合わせてAPIバックエンドやSSRに利用。	- Firebase FunctionsはFirebaseプロジェクトとの連携がより密接。
フルスタック開発フレームワーク	AWS Amplify	Firebase
	- フロントエンド開発者がバックエンド機能 (認証、データベース、ストレージ、API) を簡単に構築・連携できるプラットフォーム。 - Amplify Hostingは静的サイトホスティング、SSR (Next.jsなど) に対応。	- モバイル/Webアプリ開発プラットフォーム。 - ホスティングのほかDBや関数実行、認証などを統合。

終わりに

今までWeb技術を追いかけたことがなかったので、分類を知りませんでした。
SPA＋CSR＋PWA on Firebaseで、モダンなWebアプリを目指していこうと思います！