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的理由。