MykolaFedurko
A document moving from chat through authorization into a storage stack
View source on GitHubB1Z0N/fonlybot

projectautomationweb

Fonlybot

Historical Telegram and Google Drive bot.
  • TypeScript
  • Telegraf
  • MongoDB
  • Google APIs
Date
September 2021
Status
Historical
Visibility
Public

Fonlybot connected Telegram document intake with Google Drive and Google Docs workflows through a guided chat interface. The user-facing idea was simple: stay inside Telegram, send a document, and let the bot handle the storage and authorization path instead of asking the user to install a separate mobile app. The implementation had to do more than receive files. It had to manage chat state, language, authorization, retries, upload progress, and the point where a Telegram document becomes a Google-side artifact.

Sending a document in Telegram and watching it land in Google Drive.

The backend was a TypeScript service built around Telegraf, MongoDB, Google APIs, and webhook delivery. On startup it initialized Google authorization, opened the Mongo connection, attached chat records, ignored stale updates, loaded i18n middleware, created Mongo-backed sessions, applied throttling, registered help, auth, upload, language, and chat handlers, then launched the bot through a Telegram webhook. That setup gave the bot a real service boundary: updates were normalized before business handlers ran, and errors were logged with enough chat context to debug production behavior.

The Google side made the workflow more demanding than a plain Telegram bot. OAuth2 credentials had to be present, callback ports had to be configured, and authorization needed to survive across sessions so users were not pushed through setup on every file. The Mongo model carried asynchronous state across Telegram messages, which matters when upload flows are interrupted or when a file arrives before the user has completed authorization.

Fonlybot is historical, but it is still useful evidence of product engineering around a chat workflow. The project combines a public bot interface, webhook deployment, persistent sessions, Google API authorization, multilingual ambitions, logging, and a small promotion surface. The important part is the shape of the work: take a familiar user habit, wrap a more complex storage workflow behind it, and make the backend sturdy enough that the chat flow feels simple.

Details

Constraints
  • Mobile uploads had to survive multi-megabyte document transfers over unreliable client connections.
  • Historical status keeps the description on architecture decisions instead of active service guarantees.
Design Decisions
  • Zero-install workflow used Telegram's native file attachment UI instead of custom mobile distribution.
  • Stateless chat session design let interrupted uploads resume or roll back without corrupting Drive state.
  • Operations work included deployment, monitoring, and a promotion site around the bot workflow.
Implementation
  • Telegraf launched in webhook mode so Telegram updates arrived through a deployed hook rather than a polling loop.
  • OAuth2 token lifecycle kept Google Drive authorization renewable for background document uploads.
  • MongoDB compound index on `chat_id` and `message_id` tracked asynchronous upload state.
  • Telegraf middleware attached chat records, i18n state, Mongo-backed sessions, throttling, and stale-message filtering before handlers ran.
  • Promotion site explained the upload workflow and reduced setup friction for non-technical users.