APIアーキテクチャ選定の比較：個人開発で検証した6構成の技術評価まとめ
個人開発における API アーキテクチャ比較
個人開発を進める中で、当初はアプリ単体で完結する構成を想定していたが、
データ共有・ユーザー認証・マルチアプリ展開の必要性が高まり、
バックエンド（API）およびサーバレス基盤を選定する必要が生じた。
Swift / Firebase / FastAPI / Supabase 直結 / Next.js など複数構成を検証した結果、
最終的に React Native × Hono × Cloudflare Workers × Supabase が最適構成であると判断した。
本記事では、各構成の特徴と、技術的な採用 / 不採用理由を客観的に整理する。
1. 技術選定の前提条件
API アーキテクチャ選定は以下の前提条件を基準とした。
■ 機能要件
- iOS / Android から利用できる API
- ゲスト・通常アカウント両対応の認証
- データ永続化（RDB 必須）
- 小規模アプリ複数から共通 API を利用する構成
■ 非機能要件
- 個人開発でも継続運用できるコスト
- API レベルでの不正アクセス対策
- マルチテナント化 / SaaS 化を見据えた拡張性
- 保守運用コストの低さ
- サーバーレス構成の優先検討
2. 検討した構成の比較
以下では検討した構成を順に整理し、要件適合度を基準に採否を評価する。
2-1. Swift（iOS 単体）
■ 概要
Swift のみでネイティブアプリを構築。必要データはローカル保存。
■ 評価
● 利点
- UI を迅速に構築可能
- ネイティブ特化でパフォーマンスが高い
● 不採用理由（要件不一致）
- Android 非対応 → クロスプラットフォーム要件を満たさない
- RDB / API を内包できない → データ共有要件を満たさない
- セキュリティをアプリのみで完結させることは不適切
➡ 要件不適合のため不採用
2-2. Swift + Firebase
■ 概要
Firebase Authentication / Firestore をバックエンドとして利用。
■ 評価
● 利点
- 学習コストが低く開発速度が速い
- SDK による統合が容易
● 不採用理由（データ要件不一致）
- Android 非対応
- Firestore は RDB 要件を満たさない（JOIN / 正規化が困難）
- セキュリティルール運用が複雑で破綻リスクが高い
➡ RDB 必須要件・拡張性要件を満たさず不採用
2-3. React Native + Firebase
■ 概要
React Native を利用し、Firebase Authentication / Firestore に接続。
■ 評価
● 利点
- クロスプラットフォーム対応
- 開発速度が非常に速い
● 不採用理由（API 要件不一致）
- RDB 不可 → Firestore は要件に合致しない
- クライアント直接アクセスとなり、API ロジック層を構築できない
- 監査ログ / 署名 / 追加のセキュリティロジックを API 側で実現できない
➡ セキュリティ面で必要な要件と合致せず不採用
2-4. React Native + FastAPI + AWS
■ 概要
FastAPI（Python）を API とし、AWS RDS / Lambda / VPC を中心に構築。
■ 評価
● 利点
- 企業向けシステム並みに強固なセキュリティ設計
- 柔軟なビジネスロジックを構築可能
- PostgreSQL / MySQL / Aurora など選択肢が広い
● 不採用理由（コスト要件不一致）
- RDS・VPC・監視を含めると個人開発には過剰
- 運用コストが高く、固定費が発生しやすい
- サーバレス構成でも CloudWatch / API Gateway などの費用積み上げが大きい
➡ 費用対効果の観点から不採用
2-5. React Native + Supabase（クライアント直結）
■ 概要
Supabase（PostgreSQL + RLS）に React Native から直接アクセス。
■ 評価
● 利点
- RDB 利用が可能
- RLS により一定のセキュリティを担保
● 不採用理由（サーバ層不在）
- クライアント直結では API 層のロジックを提供できない
- 秘密鍵の管理をクライアント側に寄せる構造になりやすい
- 複数アプリで共通ロジックを扱う基盤として不十分
➡ セキュリティ面で必要な要件と合致せず不採用
2-6. React Native + Next.js（Vercel）+ Supabase
■ 概要
Next.js API Routes + Vercel Edge（KV）で API を構築する構成。
■ 評価
● 利点
- Edge Runtime による高速レスポンス
- KV キャッシュが簡単
- Web と API を統合しやすい
● 不採用理由（コスト・用途不一致）
- SSR / RSC の課金体系の影響で無料枠が枯渇しやすい
- Next.jsを「API 専用」として利用するメリットが薄い
- Workers に比べると API 特化運用のコスト効率が下がる
➡ コスト効率が低いため不採用
2-7. React Native + Hono + Cloudflare Workers + Supabase（最終構成・採用）
■ 概要
Cloudflare Workers 上で Hono を実行し API 層を構築。
Supabase（RDB＋RLS）をデータストアとし、Workers KVを併用。
■ 採用理由（重要）
● 1. セキュリティ要件を満たす
- API 層で JWT 検証、署名、Rate Limit制御が可能
- Supabase RLS との二重防御構成
- Cloudflare WAF を前段に配置可能
- anon key をアプリに配布しない構成が取れる
● 2. コストが低い
- Workers は 100k リクエスト程度なら無料枠内
- KV / キャッシュにより Supabase へのアクセス回数を抑制
- 固定費ゼロで運用可能
● 3. 拡張性が高い
- マルチアプリ展開向きの API モジュール構成
- Hono により Express のような記述で高速実装
- サーバレスでスケールするため負荷対策を気にしなくてよい
● 4. 実装効率が良い
- Workers + Hono は API 専用基盤として最適
- 簡潔なミドルウェア構成
- Supabase との連携が容易
➡ 技術要件・非機能要件を最も高いレベルで満たすため採用
3. 採用構成のアーキテクチャ図
4. 選定比較表
※ セキュリティ／コスト／拡張性は、あくまで本記事の前提条件に基づく主観評価。
| 構成 | RDB | セキュリティ | コスト | API拡張性 | 総合評価 |
|---|---|---|---|---|---|
| Swift | × | 低 | 低 | 低 | 不採用 |
| Swift + Firebase | × | 中 | 低 | 低 | 不採用 |
| RN + Firebase | × | 中 | 低 | 中 | 不採用 |
| RN + FastAPI + AWS | ○ | 高 | 高 | 高 | 不採用 |
| RN + Supabase直結 | ○ | 中 | 低 | 低 | 不採用 |
| RN + Next.js + Vercel | ○ | 中 | 中 | 中 | 不採用 |
| RN + Hono + Workers + Supabase | ○ | 高 | 非常に低 | 高 | 採用 |
5. まとめ
本記事では、個人開発プロダクトにおける API 基盤の技術選定を、
各構成の特性と要件適合性の観点から整理した。
最終的に採用した React Native × Cloudflare Workers × Hono × Supabase は、
以下の点で最も優れていた。
- API 層でのセキュリティ制御
- RDB（Supabase）と RLS の利用
- Cloudflare Workers による高いコスト効率
- サーバレス構成による柔軟なスケーリング
- マルチアプリ展開に適した構成
Discussion