Архитектура Telegram Mini App

initData, backend, платежи и границы доверия между Telegram и вашим сервером.

Зачем разбирать эту тему

Mini App — web-приложение внутри Telegram, а не доверенный backend. Любые данные клиента считаем недоверенными до серверной проверки подписи initData.

Как устроена задача на практике

Бот удобен для уведомлений и deep links, Mini App — для сложного UI, но оба слоя работают через общий backend. Внутреннее состояние заказа и сумма никогда не определяются frontend.

Что важно в production

Платёж подтверждается серверным событием провайдера, обработчик делаем идемпотентным. Start parameter помогает передать контекст, но сам по себе не выдаёт права.

Типичные ошибки

Главная ошибка — выбирать технологию или паттерн раньше, чем сформулирован пользовательский сценарий и ограничения. Второй частый промах — проверять решение только на идеальном happy path и не продумывать восстановление после сбоя, повторный запрос и права доступа.

Практический вывод

ThemeParams и safe area улучшают UX, а audit log для auth, платежей и критичных действий облегчает поддержку продукта.

  • фиксируйте допущения до реализации;
  • проверяйте решение на реальных данных и устройствах;
  • сохраняйте наблюдаемость и возможность безопасного отката;
  • усложняйте архитектуру только когда это подтверждает задача.
PSP / EDITORIAL

Есть задача, где это решение нужно применить на практике?

← Все материалыОбсудить проект ↗