Telegram Serverless: Telegram のインフラ上でボットのバックエンドコードを直接実行する

Telegram Serverless は、開発者が Telegram ボットや Mini App のバックエンドコードを Telegram のインフラ上で直接実行できるようにするプラットフォームです。高速で隔離された V8 サンドボックスを利用することで、開発者がサーバーをプロビジョニングしたり、コンテナを管理したり、スケーリングを手動で行ったりする必要がなくなります。

コアアーキテクチャとメンタルモデル

Telegram Serverless は、コードをローカルで開発し、クラウドに同期するモデルで動作します。開発者のワークフローは、主に 3 つの環境に分かれています：

• Local Project Folder: JavaScript モジュール（データベーススキーマやアップデートハンドラーを含む）が含まれます。
• The Cloud: デプロイされたモジュールと、ボットの永続的な SQLite データベースをホストします。
• tgcloud CLI: ローカルの変更をクラウドに同期するためのブリッジとして機能します。

プロジェクト構造

サーバーレスプロジェクトは、バージョン管理下にある標準的なフォルダであり、実行時にビルドステップや node_modules を必要としません。主に 3 つのコンポーネントで構成されています：

1. handlers/: ボットのエントリポイントです。各ファイルは Telegram のアップデートタイプに対応しています（例：新しいメッセージ用の message.js、ボタン押下用の callback_query.js）。プラットフォームは、アップデートを一致するハンドラーの default export 関数にルーティングします。
2. lib/: ハンドラー間で共有される JavaScript モジュールです。このディレクトリは、より良い整理のためにサブディレクトリをサポートしています。
3. schema.js: プロジェクトのルートにある単一のファイルで、型付き DSL を使用してデータベーステーブルを定義します。

データベースとスキーマ管理

すべてのボットは、専用の SQLite ベースのストアを受け取ります。プラットフォームは、スキーマ定義とクエリのために Drizzle のような ORM を使用しており、Drizzle を経験した開発者にとって馴染みのある API を提供します。

スキーマ定義とマイグレーション

テーブルは schema.js 内で名前付き export として定義されます。プラットフォームは、不測のデータ損失を防ぐために、コードのデプロイとデータのマイグレーションを分離しています。ワークフローは以下の通りです：

1. npx tgcloud push: 更新された schema.js をアップロードしますが、データベースは変更しません。
2. npx tgcloud migrate: スキーマと稼働中のデータベースの差分を計算し、変更の適用を開発者に案内します。

マイグレーションはリスクレベルによって分類されます：Safe（追加的な変更）、Warning（カラムの削除など、破壊的な変更の可能性）、および Manual（型変更など、生の SQL が必要な複雑な変更）。

データベース制約

注目すべき点として、プラットフォームは PRAGMA foreign_keys が off の状態で動作します。外部キーは DSL によってサポートされておらず、宣言するとエラーが発生します。開発者はアプリケーションロジック内で参照整合性を強制する必要があります。

プラットフォーム SDK

実行時、モジュールは単一のライブラリ sdk にアクセスできます。この SDK は 3 つの重要な機能を提供します：

• db: SQLite データベースとやり取りするためのクエリビルダーおよびスキーマ DSL です。
• api: Telegram Bot API への直接のインターフェースです。標準的なレスポンス・エンベロープを解除し、result を直接返し、ok: false が返された場合は BotApiError をスローします。
• fetch: サードパーティ API へのアウトバウンド HTTP リクエスト用の fetch-like クライアントです。AI API レスポンスのストリーミングをサポートしていますが、レスポンスの総サイズは 32 MB に制限され、バイナリペイロードはサポートされていません。

開発者ワークフローと CLI

tgcloud CLI は、ボットのライフサイクルを管理します。主なコマンドは以下の通りです：

• login: @BotFather からの CLI アクセストークンを使用して、プロジェクトをボットにリンクします。
• push: 変更されたモジュールをアトミックにデプロイプロセスの過程でデプロイします。他の開発者がより新しいリビジョンをデプロイ済みの場合、push は上書きを防ぐために拒否されます。
• run: デプロイせずにローカルファイルを使用してプラットフォーム上でハンドラーを実行し、ロジックのテストのための高速なインナーループを提供します。
• webhook sync: Telegram の webhook が、ハンドラーがデプロイされているアップデートタイプのみを配信するように正しく設定されていることを確認します。

コミュニティの洞察と検討事項

技術的な機能は広範ですが、Hacker News でのコミュニティの議論では、いくつかの未回答の質問や懸念事項が浮き彫りになりました：

• Resource Limits: ユーザーは、実行時間、ストレージ、および帯域幅の具体的なクォータ（制限）について質問しました。
• Pricing: ドキュメントにコストが明示的に記載されていないため、価格モデルに関する大きな関心が集まりました。
• Secrets Management: 開発者は、API キーや認証情報の明示的なシークレット・ストレージ・メカニズムの欠如に注目しました。これは、従来の VPS 設定では通常、環境変数を通じて扱われます。
• Accessibility: 一部のユーザーは、@BotFather 内の "Serverless" トグルがまだ表示されていないと報告しており、これは段階的なロールアウトであることを示唆しています。