Relay API设计：用Cloudflare Workers构建邮件发送基础

1。 为什么没有使用外部邮件提供商的API

制作通过电子邮件发送备忘录的应用程序时，首先想到的是大型邮件提供商的发送API。 但是，对于个人开发者来说，Google OAuth审查的门槛非常高。

Google OAuth未通过审查的应用程序会显示“此应用程序未在Google上确认”的警告画面。 对于备忘录应用程序来说，这个警告是致命的。 用户将自己的想法和个人信息作为备忘录发送。 如果第一次体验显示“未经验证”，谁会信任这个应用程序呢？

Google OAuth审查的申请过程，对于个人开发者来说是一条艰难的道路。 隐私政策的准备、范围的正当性说明、安全评估——对于大公司的团队来说，对于一个人开发的应用程序来说，为了邮件发送这一单一功能而支付的成本太大了。

需要的是，没有OAuth审查的复杂性，在不损害用户信任的情况下可以发送邮件的解决方案。 答案是自己的Relay API。

2。 Cloudflare Workers + Resend API架构

Relay API的架构既简单又坚固。 收到来自iOS应用程序的请求，转播到邮件发送服务——这是专门设计。

Cloudflare Workers是在全世界的边缘位置执行TypeScript代码的无服务器平台。 在Cloudflare的说明中，因为在名为isolate的轻度执行环境中运行代码，所以没有虚拟机型的无服务器发生的冷启动。

Resend API是现代邮件发送服务。 SPF/DKIM/DMARC易于设置，可以从TypeScript轻松调用。

在费用方面，Cloudflare Workers的免费计划可以使用到1日100000请求，Resend的免费计划可以使用1日100通·月3,000通（2026年10月时点各公司的收费页面）。 从小开始，根据发送量转为收费方案的构成。

3。 邮箱地址验证（6数字代码方式）

Relay API只向已验证的邮箱地址发送备忘录。 这是防止滥用的最基本的防御层。

在开始发送备忘录之前，需要验证发送地址的邮箱地址。

• 用户在应用程序中输入邮箱地址
• Relay API将6位数的验证码发送到该地址
• 将用户收到的6数字代码输入应用程序
• 验证完成。 之后，允许向该邮箱地址发送备忘录

通过这个机制，防止擅自向他人的邮箱发送备忘录。 验证码会发送到该地址的收件箱，所以看不到收件箱的人，无法确认该地址作为发送地址。

每个邮箱地址只验证一次。 一旦验证完成，以后无需输入代码就可以继续发送备忘录。

4。 多层速率限制的实施

为了防止邮件发送API的滥用，在多个层中实施了速率限制。

const RATE_LIMITS = {
  devicePerMinute: 30,
  devicePerDay: 200,
  ipPerHour: 120,
  globalPerDay: 300,
};

计数器保存在Cloudflare KV中，每个时间窗口都会重置。 在通过正常的发送的同时，抑制了不正当的大量访问。

5。 幂等性：为了不重复发送相同的备忘录而设计

网络通信必然存在不确定性。 从按下发送按钮到回复之间，通信可能会中断。 应用程序判断为超时，尝试重新发送，但实际上第一个请求已经到达了服务器——这是常见的场景。

在这个场景中，用幂等性（idempotency）来准备。

• 给每个备忘录赋予唯一的UUID（信息ID）
• Relay API将该消息ID作为邮件发送服务（Resend）要求的幂等键（Idempotency-Key）传递
• Resend记住了相同的按键24时间，如果再次收到相同内容的请求，不发送邮件而是返回与之前相同的回复
• 应用程序会返回成功的响应（2次也与1次相同的响应）

通过这种设计，即使网络不稳定而发生重试，在24时间内也不会重复发送相同的备忘录（Resend记住按键的期间）。 因为无法分辨之后的重新发送，所以在此期间可以停止重复。

6。 边缘计算的优点

采用Cloudflare Workers作为邮件发送基础的最大原因在于边缘计算的本质优势。

对于备忘录应用程序来说，这个组合是容易处理的选择。 在靠近用户的据点开始处理，不需要管理服务器，规模小的话费用也能控制。 这就是用边缘计算制作Relay API的理由。