なぜ私はAPIのサブドメイン分離をやめたのか？- 個人開発のコストと効率を最大化するアーキテクチャ選択
1. はじめに
こんにちは。個人開発でNuxt3を使ったWebアプリケーションを開発しているごんです。
サービスのアーキテクチャを考える上で、多くの開発者が一度は「APIのエンドポイントをどう設計するか」という問題に直面するのではないでしょうか。特に、有名サービスでよく見かける api.example.com のようなサブドメインを分離する構成は、一見すると本格的で魅力的に映ります。
しかし、今回の私のプロジェクトでは、徹底的な調査と検討の末、この「サブドメイン分離」構成の採用を見送り、「単一ドメイン統合」構成へと舵を切る決断をしました。
この記事では、その意思決定に至った背景、技術的な比較検討、そして最終的に採用したアーキテクチャがもたらす具体的なメリットについて、私の経験を基に記録します。
2. 当初検討していた構成と、その背景
当初、私は以下のようなサブドメイン分離構成を検討していました。
この構成は、フロントエンドとAPIの責務が明確に分離されており、大規模開発やマイクロサービスアーキテクチャでは標準的なアプローチです。私もこれに倣うことで、スケーラブルな設計を目指していました。
3. 直面した課題：個人開発におけるサブドメイン分離の現実
しかし、この構成を個人開発の文脈に当てはめてみると、いくつかの無視できない課題が浮かび上がってきました。
- CORS対応の複雑さ: ブラウザからフロントエンドとAPIで異なるドメイン（オリジン）にアクセスするため、CORS (Cross-Origin Resource Sharing) の設定が必須になります。これは適切な設定を行わないと、予期せぬエラーの原因となり、開発の妨げになります。
- 管理コストの増加: サブドメインごとにDNSレコードやSSL証明書を管理する必要があり、インフラの管理対象が増えてしまいます。
- 開発体験の分断: フロントエンドとバックエンドで認証情報の受け渡しや、ローカルでの開発環境の構築が煩雑になりがちです。
これらの課題は、一つ一つは解決可能ですが、個人開発というリソースが限られた状況においては、開発の速度とシンプルさを損なう大きな要因になると判断しました。
4. 発見：プロジェクト規模で異なる「最適パターン」
調査を進める中で、APIアーキテクチャの選択はプロジェクトの規模や特性に大きく依存するという、重要な発見がありました。
- 大規模SaaS・エンタープライズ: チームの独立性や外部API提供を目的として「サブドメイン分離」が主流。
- 個人開発・モダンフレームワーク: 開発効率や運用シンプルさを重視し、Next.jsやNuxt.jsが推奨する「単一ドメイン統合」が事実上の標準（デファクトスタンダード）。
この発見が、アーキテクチャを根本から見直す大きなきっかけとなりました。
5. 最終的に採用したアーキテクチャ
上記の課題と発見を踏まえ、最終的に採用したのが、CloudFrontをリバースプロキシとして活用する「単一ドメイン統合」アーキテクチャです。
この構成では、単一のドメイン (example.com) へのすべてのリクエストをCloudFrontが受け止め、パスに応じてAPIサーバーかS3（静的サイト）へリクエストを振り分けます。これにより、ブラウザから見ると常に同一オリジンへのアクセスとなり、CORSの問題が根本的に解決されます。
6. このアーキテクチャがもたらす3つのメリット
- コスト効率の向上: CloudFrontの安価なデータ転送料金とキャッシュ機能により、API Gatewayから直接配信する構成と比較して約18%のコスト削減を見込んでいます。
- パフォーマンスの改善: 静的アセットをCDNのエッジから配信することで、サイトの表示速度が最大で90%高速化されると試算しています。
- 開発・運用のシンプル化: CORS設定が不要になるだけでなく、SSL証明書やDNSの管理も一元化され、開発と運用の両面で複雑さが大幅に軽減されます。
7. おわりに
技術選定において、一般的な「ベストプラクティス」を学ぶことは非常に重要です。しかし、それ以上に大切なのは、そのプラクティスが生まれた背景を理解し、自分のプロジェクトの特性や制約に本当に合っているかを見極めることだと、今回の経験を通じて改めて実感しました。
この記事が、同じようにAPIのアーキテクチャで悩んでいる個人開発者の方にとって、一つの判断材料となれば幸いです。
Discussion