比较 API 架构选择：对个人开发中测试的六种设置进行技术评估
Source: Dev.to
请提供您希望翻译的具体文本内容，我将按照要求将其译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！
概览
当我刚开始个人开发时，我以为应用大部分可以自给自足。
然而，随着数据共享、用户认证以及多应用扩展等需求的增长，必须选择合适的后端（API）和无服务器基础设施。
在评估了多种方案——包括仅使用 Swift、Firebase、FastAPI、直接访问 Supabase 以及 Next.js——之后，我最终认为 React Native × Hono × Cloudflare Workers × Supabase 是最佳架构。
本文客观地总结了每个选项的特性，并阐述了采纳或放弃的技术原因。
选择标准
API 架构根据以下需求进行评估。
功能需求
- API 可在 iOS 和 Android 上使用
- 支持游客用户和已认证用户
- 持久化数据存储（需要关系型数据库）
- 由多个小型应用共享使用的 API
非功能需求
- 对长期个人开发而言成本可负担
- 在 API 层面防止未授权访问
- 可扩展至多租户 / SaaS 场景
- 运营和维护开销低
- 偏好无服务器架构
Evaluated Architectures
下面对每个候选架构进行审查，并评估其满足需求的程度。
2‑1. Swift (iOS Only)
概述
仅使用 Swift 构建的原生 iOS 应用，数据本地存储。
评估
| 优点 | 缺点（需求不匹配） |
|---|---|
| 快速的 UI 开发 | 不支持 Android → 未满足跨平台需求 |
| 由于原生执行，性能高 | 无法包含关系型数据库或 API 层 → 未满足数据共享需求 |
| 仅依赖客户端安全不合适 |
结果： → 因未满足需求而被拒绝
2‑2. Swift + Firebase
概述
使用 Firebase Authentication 和 Firestore 作为后端。
评估
| 优点 | 缺点（数据需求不匹配） |
|---|---|
| 学习曲线低 | 不支持 Android |
| 通过 SDK 集成实现快速开发 | Firestore 难以满足关系型数据库需求（联表和规范化困难） |
| 安全规则在大规模时变得复杂且脆弱 |
结果： → 因关系型数据库和可扩展性限制而被拒绝
2‑3. React Native + Firebase
概述
跨平台的 React Native 应用直接连接 Firebase Authentication 和 Firestore。
评估
| 优点 | 缺点（API 需求不匹配） |
|---|---|
| 跨平台支持 | Firestore 未满足关系型数据库需求 |
| 开发速度极快 | 直接客户端访问阻碍了构建完整的 API 逻辑层 |
| 审计日志、签名以及高级安全逻辑无法在服务器端强制执行 |
结果： → 因安全架构不足而被拒绝
2‑4. React Native + FastAPI + AWS
概述
使用 FastAPI（Python）作为 API 层，配合 AWS 的 RDS、Lambda、VPC 等服务。
评估
| 优点 | 缺点（成本不匹配） |
|---|---|
| 企业级安全设计 | 一旦引入 RDS、VPC 以及监控后，对个人开发而言显得过度 |
| 业务逻辑高度灵活 | 运营成本高且固定支出大 |
| 支持多种数据库（PostgreSQL、MySQL、Aurora） | 即使是无服务器方案，也会因 API Gateway 和 CloudWatch 累计费用 |
结果： → 因性价比不佳而被拒绝
2‑5. React Native + Supabase (Direct Client Access)
概述
React Native 直接连接 Supabase（PostgreSQL + RLS）。
评估
| 优点 | 缺点（无服务器层） |
|---|---|
| 完整的关系型数据库支持 | 没有 API 层来实现业务逻辑 |
| 通过行级安全（RLS）提供基础安全 | 客户端侧的密钥管理风险大 |
| 作为多应用共享后端的能力不足 |
结果： → 因安全和架构限制而被拒绝
2‑6. React Native + Next.js (Vercel) + Supabase
概述
使用 Next.js API Routes 与 Vercel Edge 结合 KV 缓存构建 API。
评估
| 优点 | 缺点（成本与用途不匹配） |
|---|---|
| Edge Runtime 提供快速响应 | SSR / RSC 计费可能快速耗尽免费额度 |
| 简单的 KV 缓存 | 当仅作 API 使用时，Next.js 的优势有限 |
| Web 与 API 的无缝集成 | 与 Workers 相比，针对 API 工作负载的成本效率较低 |
结果： → 因成本效率问题而被拒绝
2‑7. React Native + Hono + Cloudflare Workers + Supabase (Final Choice)
概述
Hono 在 Cloudflare Workers 上运行作为 API 层。Supabase（PostgreSQL + RLS）作为主数据存储，Workers KV 用于缓存。
采用原因
-
满足安全需求
- 在 API 层进行 JWT 验证、请求签名和限流
- 通过 Supabase RLS 实现深度防御
- 可在前端部署 Cloudflare WAF
- 无需将 Supabase 的匿名密钥分发给客户端
-
低成本
- Workers 的免费额度足以支撑大多数个人或小型项目的请求量
- KV 缓存进一步降低对数据库的直接访问次数，节约费用
Source: …
free under ~100 k requests/month
- KV and caching reduce Supabase query volume
- Zero fixed operational cost
- High Scalability
- API modularization suitable for multi‑app expansion
- Hono provides Express‑like ergonomics with high performance
- Serverless scaling removes infrastructure concerns
- High Development Efficiency
- Workers + Hono are optimized for API‑only use
- Simple middleware composition
- Smooth integration with Supabase
Result: → Adopted as it best satisfies both technical and non‑functional requirements
架构图
[ React Native App ] [ Cloudflare Workers (Hono) ] [ Supabase (PostgreSQL + RLS) ]
|
v
[ Workers KV (cache) ]详细图
|
HTTPS
|
[ Cloudflare Workers (Hono API) ]
|
+--> JWT Verify -----> [ Supabase Auth ]
|
+--> SQL + RLS ------> [ Supabase PostgreSQL ]
|
+--> Rate Limit -----> [ Workers KV ]比较表
安全性、成本和可扩展性是基于本项目假设的主观评估。
| 架构 | RDB | 安全性 | 成本 | API 可扩展性 | 综合 |
|---|---|---|---|---|---|
| Swift | ✗ | 低 | 低 | 低 | 拒绝 |
| Swift + Firebase | ✗ | 中 | 低 | 低 | 拒绝 |
| RN + Firebase | ✗ | 中 | 低 | 中 | 拒绝 |
| RN + FastAPI + AWS | ✔ | 高 | 高 | 高 | 拒绝 |
| RN + Supabase (Direct) | ✔ | 中 | 低 | 低 | 拒绝 |
| RN + Next.js + Vercel | ✔ | 中 | 中 | 中 | 拒绝 |
| RN + Hono + Workers + Supabase | ✔ | 高 | 极低 | 高 | 采用 |
Summary
本文比较了个人发展项目的多种 API 架构，并根据功能性和非功能性需求对每个选项进行评估。
最终选择的 React Native × Cloudflare Workers × Hono × Supabase 之所以脱颖而出，是因为：
- 强大的 API 级别安全控制
- 通过 Supabase 及行级安全（RLS）提供可靠的关系型数据库支持
- 通过 Cloudflare Workers 实现卓越的成本效益
- 灵活的无服务器扩展能力
- 结构适合多应用扩展。