Вариант 3 — это «золотая середина» между ручным управлением и сложными системами очередей типа Celery. Вот как это работает на уровне архитектуры и как это будет выглядеть для тебя.
1. Как это устроено технически
FastAPI предоставляет встроенный механизм BackgroundTasks. Работает это так:
- Админ нажимает кнопку «Запустить фоновую синхронизацию».
- Браузер отправляет запрос на сервер.
- Сервер говорит: «Ок, задачу принял, погнали!» и мгновенно возвращает ответ
HTTP 202 Accepted. - Важно: HTTP-соединение разрывается, браузер свободен, но процесс на сервере продолжает жить и выполнять код синхронизации в фоне.
2. Что нужно доработать в коде
Чтобы это было удобно и надежно, нам понадобятся три вещи:
А. Сервисная функция «Вечного цикла»
Мы создаем функцию, которая в цикле вызывает наш существующий sync_missing_moves_batch до тех пор, пока:
- Либо не закончатся игры без ходов.
- Либо не будет достигнут лимит (например, 10 000).
- Либо не произойдет критическая ошибка.
Б. Отслеживание статуса (State)
Поскольку процесс идет в фоне, нам нужно знать: «Он еще работает? Сколько уже скачано? Были ли ошибки?». Самый простой способ для нашего проекта — хранить это в памяти сервера (в синглтоне) или в маленькой таблице в БД.
- Пример статуса:
{ "status": "running", "processed": 450, "total": 10000, "errors": 2 }
В. Эндпоинт для проверки (Polling)
Фронтенд будет раз в пару секунд «стучаться» на сервер по адресу /api/admin/sync/status, забирать этот JSON и красиво рисовать полоску прогресса.
3. Плюсы этого подхода
- Удобство: Вы нажали кнопку, увидели, что процесс пошел, и можете закрыть ноутбук или уйти на другую страницу.
- Безопасность для UI: Никаких зависших вкладок и «белых экранов» из-за долгих ожиданий.
- Контроль: Мы можем добавить кнопку «Остановить синхронизацию», которая просто поменяет флаг в памяти сервера, и цикл завершится на следующей итерации.
4. Риски (и как их лечить)
- Перезагрузка сервера: Если вы обновите код (сделаете деплой), пока идет синхронизация, фоновая задача умрет.
- Решение: При запуске сервера проверять, есть ли еще игры без ходов, и (опционально) предлагать продолжить.
- Утечки сессий БД: В фоновых задачах нужно очень аккуратно работать с
db_session, чтобы не оставить открытых соединений. - Блокировка Dice Chess: Если мы запустим «вечный» цикл без пауз, нас забанят.
- Решение: Мы оставим тот же
delay_msмежду играми.
- Решение: Мы оставим тот же
Итоговый сценарий использования:
- Ты заходишь в админку.
- Видишь: «Пропущено ходов: 10 240».
- Вводишь лимит «10 000» и жмешь «Run in Background».
- Появляется плашка: «Синхронизация запущена. Обработано: 124/10000…».
- Ты можешь закрыть админку. Если зайдешь через 10 минут — она подхватит статус и покажет актуальный прогресс.
Как тебе такая схема? Если нравится, я могу набросать Implementation Plan, как мы внедрим этот механизм в бэкенд и фронтенд.