Telegram Serverless
211 points
• 2 days ago
• Article
Link
Telegram Serverless 提供了一个简洁的运行环境，可以直接在 Telegram 的基础设施上托管 bot 后端和 Mini App 的逻辑。平台免去了配置服务器、管理容器和处理扩容的繁琐工作，开发者只需编写在独立且高速的 V8 沙箱中运行的 JavaScript 模块。平台内置对 Telegram Bot API 、基于 SQLite 的数据库与出站 HTTP 的支持，让开发者能把精力放在应用逻辑上，而无需操心基础设施维护。
开发流程对习惯使用标准版本控制的开发者来说非常熟悉。每个项目由一个专用文件夹组成，包含三类主要内容：数据库的 schema 定义、可复用的共享库，以及针对特定 Telegram update 类型的独立处理器（handler）。开发者通过 tgcloud 命令行工具在本地项目与云端之间交互，用于推送代码、执行数据库迁移（migrations）以及在部署前进行本地测试。
平台的一项核心设计原则是将代码部署与数据库状态管理明确分离。代码更新可以原子性地推送并生效，但任何数据库 schema 的变更都必须通过单独且有意识的迁移步骤才会执行。平台会按风险对 schema 修改进行分类：增量变更可以直接应用，而像删除表这类潜在破坏性的操作则需要逐项确认。这样可确保常规的代码推送不会意外更改或删除数据，为生产环境提供保护。
平台提供了完整的 Software Development Kit，简化了与外部服务和内部状态的交互。 Bot API 被原生集成，调用结果会自动解包以便使用；内置的数据库查询构建器支持流畅的异步持久化操作。对外连接方面，平台提供了支持流式传输的 fetch 实现，方便接入第三方 API 。为便于调试，平台会捕获所有 console 输出，这些输出既可在本地测试时实时查看，也可在移动端通过 BotFather 界面查看。
协作与并发采用基于 revisions 的乐观模型。当多个开发者或多台机器尝试向同一 bot 推送更改时，平台会检测冲突并拒绝推送，避免意外覆盖。开发者需先将本地环境与云端的最新状态同步后再重试。无论是在命令行下开发，还是通过 BotFather 在移动端操作，项目结构保持一致，提供灵活且高度可移植的开发体验，并能随 bot 的需求自动扩展。
Telegram Serverless provides a streamlined environment for hosting bot backends and Mini App logic directly on Telegram's own infrastructure. By eliminating the need to provision servers, manage containers, or handle scaling, the platform allows developers to write JavaScript modules that run in fast, isolated V8 sandboxes. This setup includes built-in support for the Telegram Bot API, an SQLite-backed database, and outbound HTTP, ensuring that developers can focus on application logic rather than infrastructure maintenance.
The development workflow is designed to be familiar to those using standard version control. Projects consist of a dedicated folder containing three primary components: a schema definition for the database, a set of shared libraries for code reuse, and individual handlers that correspond to specific Telegram update types. Developers interact with this environment through the tgcloud command-line interface, which bridges the local project folder and the cloud. This interface supports common tasks such as pushing code updates, performing database migrations, and testing logic locally before any deployment occurs.
One of the platform's core design principles is the deliberate separation of code deployment and database state management. While code updates are pushed to the cloud and made live atomically, changes to the database schema require a separate, intentional migration step. This process is highly controlled, with the platform categorizing schema modifications by risk. Additive changes are applied easily, while potentially destructive actions like dropping tables require explicit, individual confirmation. This structure ensures that a routine code push never inadvertently alters or deletes data, providing a safety net for production environments.
The platform provides a comprehensive Software Development Kit that simplifies interactions with external services and internal state. The Bot API is natively integrated, with results automatically unwrapped for easier consumption, while the database query builder allows for fluent, asynchronous interaction with persistent data. For external connectivity, the platform offers a fetch implementation that supports streaming, enabling developers to integrate third-party APIs seamlessly. To further aid in debugging, the platform captures all console output, which can be viewed in real-time during local testing or via the BotFather interface when developing directly on a mobile device.
Collaboration and concurrency are handled through an optimistic model that tracks revisions. If multiple developers or machines attempt to push changes to the same bot, the platform detects the conflict and rejects the push, preventing accidental overwrites. Developers can then synchronize their local environments with the latest cloud state before proceeding. Whether building via the command line or on the go through BotFather, the project structure remains consistent, allowing for a flexible and highly portable development experience that scales automatically with the bot's needs.
106 comments • Comments Link
• 新的 Telegram serverless 平台允许开发者用 JavaScript 编写 bot 逻辑，并直接在 Telegram 的基础设施上运行，从而免去了外部托管，简化了部署流程。
• 不过，该平台目前缺乏 Secrets 管理、依赖管理、 TypeScript 支持和定时任务（Cron jobs）等常见开发者便利功能，与 Cloudflare Workers 等替代方案相比，显得尚不成熟。
• 平台通过 V8 isolates 实现租户隔离，但在资源配额、带宽限制以及所提供的 SQLite 数据库的持久性保证等方面仍缺乏明确说明。
• 有人指出，从网络架构上看该平台并非传统意义上的全球分布式——bot 的交互与分配给该账户的特定数据中心绑定。
• 大家对平台的商业模式和长期可持续性表示担忧，尤其考虑到 Telegram 过去优先支持 Crypto 项目的历史，未来可能出现的服务波动或商业化风险令人警惕。
• 关于 Bot API 的价值争论仍在继续：一些人认为像 Signal 这类平台缺乏 Bot API 是出于安全和隐私的考量，而另一些人则认为基于 Bot 的自动化对提升个人生产力非常重要。
• 与 Telegram 相对开放且对开发者友好的生态相比，WhatsApp 的企业限定 API 被普遍认为在可接入性和成熟度上远不如前者。
• 许多用户指出平台文档明显带有 AI 生成痕迹，表现为冗余副词、过度使用破折号以及一种独特的"简洁"结构等风格特征。
• 对 AI 撰写文档的看法分歧：有些人将其视为敷衍或不可靠的信号，另一些人则把它当作解决开发者通常不愿编写文档问题的务实工具。
• 平台对文本响应的限制以及无法创建自定义 SSL sockets 的事实表明，Telegram 在严格控制出站流量，以防止数据抓取或代理用途。
总体来看，对这个新的 serverless 平台的反应褒贬不一：它在极大便利性与透明度不足之间存在权衡。尽管把 bot 托管直接集成到消息平台中降低了入门门槛，但技术用户因资源限制不明、缺乏 Secrets 管理和不透明的路线图而保持怀疑。此次讨论也反映出开发者社区对无处不在的 AI 生成内容的更广泛紧张感——当文档缺乏"人味"时，许多人会感到疲惫或恼火。总体而言，该平台被视为 Telegram 生态中一个有趣但仍处于早期的实验性扩展。 • The new Telegram serverless platform enables developers to write bot logic in JavaScript that executes directly on Telegram's infrastructure, simplifying deployment by removing the need for external hosting.
• Lack of support for standard developer amenities like secrets management, dependency management, TypeScript, and cron jobs makes the platform feel immature compared to alternatives like Cloudflare Workers.
• The platform relies on V8 isolates for tenant isolation, yet there is a lack of clarity regarding resource quotas, bandwidth limits, and persistence guarantees for the provided SQLite database.
• Discussion arose regarding Telegram's network architecture, noting that the platform is not globally distributed in a traditional sense, as bot interactions are tied to the specific data center assigned to the account.
• Concerns exist regarding the platform's business model and long-term viability, especially given Telegram's history of prioritizing crypto initiatives and the potential for service instability or future monetization.
• The debate over bot APIs continues, with some viewing the absence of such APIs as a security and privacy benefit of platforms like Signal, while others argue that bot-driven automation is an essential tool for personal productivity.
• WhatsApp's enterprise-only API model is seen as significantly less accessible and mature compared to Telegram's open, developer-friendly ecosystem.
• Many users identified the provided documentation as clearly AI-generated, citing specific stylistic patterns like redundant adverbs, overuse of em-dashes, and a distinct "punchy" structure.
• Opinions on AI-written documentation are divided, with some feeling it signals a lack of care or reliability, while others view it as a pragmatic tool for documentation that developers traditionally dislike writing.
• The platform's restriction to textual responses and inability to create custom SSL sockets suggests that Telegram is maintaining strict control over outgoing traffic to prevent scraping or proxy usage.
The reception of the new serverless platform is mixed, centered on the trade-off between extreme convenience and a lack of transparency. While the integration of bot hosting directly into the messaging platform lowers the barrier to entry, technical users remain skeptical due to the absence of clear resource limits, secrets management, and a transparent roadmap. The conversation further reflects a broader tension in the developer community regarding the ubiquity of AI-generated content, with many users expressing fatigue or irritation when documentation lacks a human touch. Ultimately, the platform is viewed as an interesting, albeit early-stage, experimental expansion of Telegram's ecosystem.