Все кейсы
Разработка Telegram Mini App // фитнес

Разработка Telegram Mini App для фитнес-тренера: кейс Fit Bot

Fit Bot начинался как быстрый MVP на Google Таблицах. Когда появились роли тренера и клиента, программы, подходы, питание и уведомления, проект перевели на FastAPI и обычную базу данных. Разбираем, как устроен вход из Telegram, почему таблиц стало мало и какие ошибки пришлось исправить.

Первая версия
Google Sheets для быстрого MVP
Архитектура
FastAPI, SQLAlchemy, React и Telegram HMAC
Сценарии
Роли тренера и клиента, программы, питание и прогресс

Что получает заказчик

Telegram Mini App открывается из привычного бота, но работает как отдельное приложение. Тренер приглашает клиентов, собирает программы и видит сводку. Клиент записывает тренировку, питание и прогресс. Backend проверяет подпись Telegram и права на каждое действие. Такой формат подходит для пилота сервиса без установки приложения из магазина.

Как проходит вход из Telegram

WebApp получает подписанный initData и передаёт его API. Сервер проверяет HMAC, срок данных и только после этого определяет роль. Telegram ID из браузера без подписи не считается авторизацией.

Frontend использует роль для маршрута и интерфейса, но права повторно проверяются на backend. Клиент не может получить чужой профиль ручной подстановкой ID.

Telegram /start
  → открыть WebApp
  → Authorization: tma <initData>
  → GET /api/v2/auth/me
  → кабинет тренера или клиента

Почему ушли от Google Sheets

Таблица помогла быстро проверить сценарий. Затем один тренер стал связан с несколькими клиентами, программа — с днями и упражнениями, а упражнение — с планом и фактическими подходами. Появились параллельные записи и ограничения доступа.

После проверки идеи таблицы оставили в первой версии, а рабочую модель данных перенесли в SQLAlchemy. Для небольшого локального запуска подходит SQLite, для постоянной работы с параллельными пользователями — PostgreSQL.

Что пришлось исправлять

  1. 01Сводка тренера делала несколько SQL-запросов на каждого клиента. Её заменили пакетными выборками, а тяжёлые метрики оставили в детальной карточке.
  2. 02Временный адрес API менялся после перезапуска туннеля. Для стабильной версии нужен постоянный домен, иначе приходится обновлять frontend и пересобирать приложение.
  3. 03Тестовое окружение подставляло упрощённую авторизацию, а ручной запрос получал 401. Мы разделили режимы явно и не ослабляли проверку подписи в рабочем сценарии.
  4. 04Экран тарифа появился раньше платёжной интеграции. Полноценная оплата требует счёта, подтверждения Telegram и защиты от повторной обработки одного события.

Что нужно для постоянного запуска

  1. 01Перенести рабочие данные в PostgreSQL и применять изменения схемы через миграции.
  2. 02Разделить API и Telegram-бота на два управляемых сервиса с автоматическим перезапуском.
  3. 03Привязать постоянный API-домен, ограничить CORS и добавить проверку состояния сервиса.
  4. 04Пройти настоящий вход из Telegram и проверить права тренера и клиента на тестовых аккаунтах.
  5. 05Проверить резервное копирование и восстановление до подключения реальных пользователей.

Материалы и ссылки

SYSTEM: ONLINE // V.1.1
СТАТЬИFIT-BOTPRIVACYCOPYRIGHT 2025-2026
SYS: COOKIE

Мы используем технические cookies (Cloudflare) для корректной работы сайта. Политика конфиденциальности