Telegram Serverless: 直接在 Telegram 基礎設施上執行 Bot 後端程式碼

Telegram Serverless: 直接在 Telegram 基礎設施上執行 Bot 後端程式碼

Telegram Serverless 是一個讓開發者可以直接在 Telegram 的基礎設施上執行 Telegram bot 和 Mini App 後端程式碼的平台。透過利用快速且隔離的 V8 sandbox，該平台免除了開發者配置伺服器、管理容器或手動處理擴展的需求。

核心架構與心智模型

Telegram Serverless 運作於一種程式碼在本地開發並同步到雲端的模型。開發者工作流被拆分為三個主要環境：

  • Local Project Folder: 包含 JavaScript 模組，包括資料庫 schema 和 update handlers。
  • The Cloud: 託管已部署的模組和 bot 的持久化 SQLite 資料庫。
  • tgcloud CLI: 作為將本地變更同步到雲端的橋樑。

專案結構

A serverless 專案是一個受版本控制的標準資料夾，在執行時不需要 build step 或 node_modules。它由三個主要組件組成：

  1. handlers/: Bot 的進入點。每個檔案對應一個 Telegram update type（例如，message.js 用於新訊息，callback_query.js 用於按鈕點擊）。平台會將 updates 路由到匹配的 handler 的 default export function。
  2. lib/: 在 handlers 之間共用的 JavaScript 模組。此目錄支援子目錄以進行更好的組織。
  3. schema.js: 位於專案根目錄的單一檔案，使用強型別 DSL 定義資料庫資料表。

資料庫與 Schema 管理

每個 bot 都會獲得一個專用的 SQLite 託管存儲。平台使用類似 Drizzle 的 ORM 來進行 schema 定義和查詢，為熟悉 Drizzle 的開發者提供熟悉的 API。

Schema 定義與遷移 (Migrations)

資料表在 schema.js 中定義為 named exports。平台將程式碼部署與資料遷移分開，以防止意外的資料遺失。工作流如下：

  1. npx tgcloud push: 上傳更新後的 schema.js 但不修改資料庫。
  2. npx tgcloud migrate: 計算 schema 與現有資料庫之間的差異，並引導開發者執行變更。

遷移被分為不同的風險等級：Safe（增量變更）、Warning（可能具破壞性的變更，例如刪除欄位）以及 Manual（複雜的變更，例如需要原始 SQL 的型別變更）。

資料庫約束 (Constraints)

值得注意的是，平台在執行時將 PRAGMA foreign_keys 設為 off。DSL 不支援外鍵，若宣告則會拋出錯誤。開發者必須在應用程式邏輯中強制執行參照完整性。

平台 SDK

在執行時，模組可以存取單一函式庫：sdk。此 SDK 提供三個核心能力：

  • db: 用於與 SQLite 資料庫互動的查詢構建器 (query builder) 和 schema DSL。
  • api: 直接與 Telegram Bot API 互動的介面。它會解包標準的 response envelope，直接回傳 result，若 ok: false 則會拋出 BotApiError。
  • fetch: 用於向第三方 API 發送外部 HTTP 請求的 fetch-like client。它支援 AI API 回應的串流 (streaming)，但將總回應大小限制在 32 MB 以內，且不支援二進位負載 (binary payloads)。

開發者工作流與 CLI

tgcloud CLI 管理 bot 的生命週期。關鍵指令包含：

  • login: 使用來自 @BotFather 的 CLI access token 將專案連結至 bot。
  • push: 原子化地部署變更後的模組。如果另一位開發者已部署了較新的版本，push 會被拒絕以防止覆蓋工作。
  • run: 在平台上使用本地檔案執行 handler，而無需部署，為測試邏輯提供快速的內迴圈 (inner loop)。
  • webhook sync: 確保 Telegram webhook 已正確配置，以便僅傳遞已部署 handler 的 update types。

社群觀察與考量因素

雖然技術能力非常強大，但 Hacker News 上的社群討論突顯了幾個尚未解答的問題與疑慮：

  • 資源限制: 使用者詢問了關於執行時間、儲存空間和頻寬的具體配額。
  • 定價: 對定價模式有很大的好奇心，因為文件尚未明確說明成本。
  • 機密資訊管理 (Secrets Management): 開發者指出缺乏明確的 API key 和憑證的機密資訊存儲機制，而在傳統 VPS 設定中，這些通常透過環境變數處理。
  • 可及性: 部分使用者回報 @BotFather 中的 "Serverless" 切換開關尚未對他們可見，這顯示了分階段推出的策略。

Sources