Как я собираю Plexora — игровой магазин внутри MAX Последние дни я занимаюсь Plexora — игровым магазином внутри мессенджера MAX. Проект состоит из публичного канала, Mini App-витрины и серверного ядра, которое отвечает за обработку заказов и интеграции с поставщиками. Главная задача сейчас — собрать систему так, чтобы публичная часть была максимально простой и безопасной, а внутренняя логика оставалась изолированной. Сейчас архитектура устроена следующим образом. Публичный канал Plexora отвечает за контент, акции, новости и переход в магазин. Отдельный публичный бот будет точкой входа для покупателя. Mini App — это сам магазин с каталогом, регионами, номиналами и ценами. Storefront API работает отдельным сервисом только на чтение. ResellFlow остаётся внутренним ядром, где находятся заказы, поставщики, экономика и автоматизация. Служебный бот используется только для внутренних уведомлений владельцу. Пользовательский путь получается достаточно простым: канал → публичный бот → Mini App → Storefront API → ResellFlow. Storefront я вынес в отдельный процесс со своей конфигурацией. Он не имеет доступа к внутренним секретам ядра, не выполняет закупки и не обращается к внешним сервисам. Данные читаются из общей базы в режиме read-only. Для публичного API используется отдельная проекция данных по белому списку. Наружу попадают только те поля, которые действительно нужны витрине. Внутренние SKU, настройки поставщиков, маржа, токены и служебные параметры не выдаются. Mini App уже умеет проверять данные запуска MAX на сервере. Используется HMAC-подпись, контроль свежести данных и безопасное сравнение. Если проверка не проходит, клиент получает нейтральный отказ без технических деталей. Каталог переработан по схеме «игра → регион → номинал». Например, Free Fire для одного региона теперь не размножается на несколько почти одинаковых карточек. Пользователь видит один регион и выбирает нужный номинал внутри него. Интерфейс сделан mobile-first, есть адаптация под более широкий экран, состояния загрузки, ошибки и пустого каталога. Интересная проблема возникла не в коде, а в продуктовой логике. Изначально Mini App была подключена к моему техническому боту ResellFlow Monitor. С точки зрения backend всё работало, но MAX показывает имя бота над Mini App. Для покупателя над магазином появлялась надпись «ResellFlow Monitor», что выглядело неправильно. Поэтому решил разделить роли. ResellFlow Monitor остаётся внутренним техническим ботом. Plexora получает отдельного публичного бота. Канал отвечает за контент и привлечение. Mini App остаётся витриной магазина. При этом сам механизм авторизации менять не нужно. Достаточно будет заменить токен и имя бота в конфигурации storefront. Сейчас основной набор тестов проходит полностью: 633 из 633. Также проходят статический анализ, проверка типов, storefront build-check, smoke tests и safe E2E. Отдельно проверяется, что публичный API не отдаёт служебные данные, а storefront не зависит от внутренних модулей уведомлений и закупок. Один браузерный тест иногда нестабилен при полном прогоне под нагрузкой, хотя отдельно проходит стабильно. Его вынес в отдельную техническую задачу. Ещё один вывод — при работе с боевой системой лучше использовать модель «ассистент готовит, человек выполняет». Я не даю агенту автоматически деплоить изменения на VPS. Команды выполняю вручную и после каждого шага проверяю результат. Дальше планирую создать отдельного публичного бота Plexora, перенести на него Mini App, расширить каталог по регионам, добавить обложки товаров, реализовать ввод UID и оформление заказа, подключить оплату с идемпотентностью, добавить историю заказов, аналитику, FAQ и поддержку. Покупка сейчас намеренно отключена. Сначала хочу закончить безопасный контур, а уже потом включать реальные платежи. Главный принцип проекта для меня сейчас простой: публичная часть должна знать о внутренней системе как можно меньше. Это упрощает развитие продукта и сильно снижает риск ошибок.