React + Firebase：生产 ERP 的架构决策

Source: Dev.to

请提供您想要翻译的具体内容（文章正文），我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！

构建 ERP 不是副业

它处理真实的金钱、真实的税务义务以及真实的业务数据。每一个架构决策都会产生后果，并在数月内累积。

下面是我为 Frihet 选择的技术栈以及每个决策背后的理由。

技术栈

Frontend:  React 18 + TypeScript + Vite 5
Styling:   Tailwind CSS + shadcn/ui + Radix
Backend:   Firebase (Auth, Firestore, Cloud Functions, Storage)
AI:        Google Gemini (2.5 Flash + Pro)
Payments:  Stripe Billing + Connect
Hosting:   Vercel (frontend) + GCP europe‑west1 (backend)
Mobile:    Capacitor (iOS + Android from same codebase)

为什么选择 Firebase 而不是传统后端

我是一名独立开发者，要打造一个可以与拥有上千万资金的公司竞争的产品。我要同时管理数据库集群、处理迁移、进行连接池管理以及开发功能，这几乎不可能。

Firebase 为我提供了：

• Auth – 邮箱、Google、GitHub、Microsoft（零自定义代码）
• Firestore – 实时订阅；数据变更会立即推送到所有已连接的客户端
• Cloud Functions – 服务器端逻辑；按需伸缩，无空闲成本
• Security Rules – 在数据库层面强制数据隔离，而不是在应用代码中实现

权衡在于供应商锁定和 NoSQL 数据模型。对于需要快速交付的独立创始人来说，这种权衡是合理的。

NoSQL 的挑战

ERP 传统上是关系型的。让 Firestore 正常工作需要严格的数据建模纪律：

• 在数据库层面的工作区隔离 – 每个业务租户拥有自己的数据分区。即使应用代码出现 bug，跨租户的数据泄漏也不可能，因为安全规则会强制执行。
• 读取时去规范化，写入时使用引用 – 发票列表视图直接展示客户名称，无需额外查询，但所有变更都必须通过规范的客户记录进行。
• 使用 Cloud Functions 进行复杂聚合 – 任何类似 SQL JOIN 或 GROUP BY 的操作都在服务器端执行，而不是在客户端。

这种方式能够满足约 80 % 的使用场景。剩余约 20 %（复杂报表、跨实体查询）需要的工程量要比使用 PostgreSQL 更大。

无状态库的状态管理

不使用 Redux。也不使用 Zustand。更不使用 MobX。

Firebase 本身就是状态存储。 数据流如下：

User action → hook → Firestore write → onSnapshot → React re‑render

没有本地状态需要同步，因为 Firestore 是唯一的真相来源。乐观更新用于弥补延迟；当写入确认后，snapshot 监听器触发，React 重新渲染并使用持久化的数据。

这消除了整类 bug：陈旧状态、同步冲突、缓存失效。数据库永远是正确的。

财务计算：唯一真相来源

西班牙有增值税 (21 / 10 / 4 %)，加那利群岛有 IGIC (7 / 3 / 0 %)，自由职业者还有 IRPF 预扣 (‑15 %)。一次错误的四舍五入就会导致报税错误。

所有税费计算、总额计算以及四舍五入操作都 集中 在同一个引擎中。绝不要在组件里直接写数学公式。修复一次税务 bug，就能同时在所有发票、报价、费用和报表中生效。

// 所有财务操作都走同一个引擎
import { calculateTotal } from '@/lib/calculations';

// 无论是发票、报价还是费用
const result = calculateTotal(lineItems, { taxType, withholding });

AI 作为一等公民，而非附加功能

AI 副驾并不是围绕 UI 的聊天机器人包装器。它拥有类型化的函数定义，能够通过前端使用的同样 API 操作真实的用户数据。

关键架构决策

1. 函数调用，而非 RAG – AI 调用结构化函数并传入类型化参数。

   create_invoice({ clientId, items, taxRate })

   这消除了歧义；自然语言搜索则不具备这种确定性。
2. 懒加载 – AI 模块体积较大，仅在用户需要时才加载。

（未完，续下篇）

Source: …

rst 与聊天交互。预加载在鼠标悬停聊天按钮时开始，因此当用户点击时，模块已经准备就绪。
3. 上下文注入 – 系统提示包含用户的实际业务上下文（活跃客户、最近的发票、税务义务）。AI 在真实数据上运行，而不是猜测。
4. 安全边界 – AI 使用与 UI 相同的权限模型。它无法访问用户无法访问的数据。函数调用遵循相同的安全规则。

大规模 i18n：17 种语言

• 不是机器翻译的标签 – 完整本地化，包括财政术语。
• 翻译流水线：先使用 240 K 条目、匹配率 97.8 % 的翻译记忆库，然后仅对缺口使用 AI。
• 成本从 $3.36 降至 $0.30 每次完整翻译运行 – 下降 91 %。
• 所有 17 种语言保持同步。CI 检查会阻止任何缺少翻译键的提交。

性能结果

“构建 AI 原生 ERP” 第 3 部分。前文： 55‑Tool MCP Server · Why I Built It Solo.

接下来：为什么传统 ERP 已经死亡

Frihet — 免费、AI 原生 ERP。
Try it · Docs · npm