Разработка торгового бота с веб-интерфейсом управления
Торговый бот без нормального UI — это чёрный ящик, который либо делает деньги, либо нет. Веб-интерфейс управления превращает его в контролируемую систему: оператор видит, что происходит, может вмешаться, изменить параметры, остановить в нужный момент. Это не «красивый дашборд», это инструмент управления рисками.
Архитектура: разделение bot core и UI
Первое правило: бот-ядро не должно зависеть от UI. Если веб-сервер упал — торговля продолжается. Если UI завис — позиции не теряются. Архитектура строится так:
Bot Core (Go/Python)
├── Strategy Engine
├── Order Manager
├── Risk Manager
└── State Store (Redis/DB)
↕ (WebSocket/REST API)
Web Backend (Node.js/FastAPI)
└── Web Frontend (React/Vue)
Bot core экспонирует internal API — либо REST, либо gRPC, либо прямой доступ к Redis pub/sub. Web backend подписывается на события бота и транслирует их во фронтенд через WebSocket.
Real-time updates
Ключевое требование UI для торгового бота — данные должны обновляться в реальном времени. P&L, открытые позиции, последние сделки, баланс — всё это меняется на каждом тике. Подходы:
WebSocket streaming: backend держит WS-соединение с ботом, пробрасывает события во фронтенд. Минимальная задержка, но сложнее в реализации reconnect-логики.
Server-Sent Events (SSE): проще WebSocket, достаточно для большинства use cases. Одностороннее соединение сервер → клиент.
Polling: самый простой, но даёт latency. Приемлемо для некритичных данных (история сделок, статистика за день).
На практике: WebSocket для P&L и positions, polling каждые 5-30 секунд для конфигурации и истории.
Ключевые компоненты интерфейса
Dashboard — главный экран
Должен дать полную картину за 3 секунды просмотра:
| Компонент | Данные |
|---|---|
| Portfolio summary | Общий баланс, дневной P&L, открытые позиции |
| Bot status | Running/Stopped/Error, uptime, последний heartbeat |
| Active positions | Инструмент, сторона, размер, unrealized PnL |
| Recent trades | Последние 10-20 сделок с результатом |
| Risk indicators | Текущая загрузка по лимитам, drawdown |
Управление стратегиями
Список активных стратегий с возможностью:
- Старт/стоп отдельной стратегии без остановки бота
- Изменение параметров на лету (если бот поддерживает hot-reload)
- Просмотр equity curve по каждой стратегии
- Allocation капитала между стратегиями
Конфигурация и параметры
Форма редактирования параметров бота должна учитывать: не все параметры можно менять на ходу. Одни применяются сразу, другие — только после перезапуска стратегии. UI должен это явно коммуницировать.
Важно валидировать параметры на фронте до отправки: если человек вводит max_position_size = 1000000 при балансе 10000, это должно подсветиться как предупреждение, а не молчаливо применяться.
Аутентификация и безопасность
Веб-интерфейс бота — критически важный endpoint. Компромисс интерфейса = компромисс торгового счёта.
Обязательный минимум:
- HTTPS с валидным сертификатом (Let's Encrypt + nginx)
- Multi-factor authentication — TOTP (Google Authenticator / Authy)
- IP whitelist — доступ только с доверенных адресов
- Session timeout — автовыход после неактивности
- Audit log — запись всех действий пользователя с timestamp
Action confirmation: деструктивные действия (остановка бота, закрытие всех позиций, изменение риск-лимитов) требуют дополнительного подтверждения. Modal с текстом действия и кнопкой "Подтвердить".
Стек и реализация
Backend: FastAPI (Python) или Express (Node.js). FastAPI удобен, если бот тоже на Python — единая кодовая база.
Frontend: React с TypeScript. Для real-time графиков — lightweight-charts от TradingView (open source, нативная поддержка финансовых данных). Для таблиц с сортировкой и фильтрацией — TanStack Table.
State management: Zustand или Jotai — проще Redux для подобных приложений. Данные с WebSocket обновляют стор, компоненты рендерятся реактивно.
Деплой: nginx как reverse proxy перед backend, SSL termination на уровне nginx. Фронтенд — статика, раздаётся тем же nginx или CDN.
Веб-интерфейс для торгового бота — это не прототип на localhost. Это продакшен-система, которая должна работать 24/7, иметь graceful degradation при сетевых проблемах и не терять данные при перезагрузке браузера.