BACKEND / ФОНОВЫЕ ЗАДАЧИ
Upscale Service
Обработка изображения не должна держать HTTP-запрос открытым.
Flask принимает файл, Celery выполняет увеличение изображения нейросетью EDSR, а клиент получает результат по идентификатору задачи.
- Backend
- Flask
- Очередь
- Celery / Redis
- Обработка
- OpenCV / EDSR ×2
01 / CONTEXT
Что здесь интересно
Не сама модель, а работа с долгой задачей: быстро принять файл, отдать идентификатор, отдельно получить статус и скачать результат.
02 / FLOW
Путь одного изображения
- 01
POST /upscale
Проверка наличия файла и расширения; сохранение входных байтов в Redis с TTL.
- 02
Очередь Celery
Клиент получает UUID задачи; обработчик отдельно читает изображение и увеличивает его.
- 03
GET /tasks/{id}
API возвращает текущее состояние задачи и адрес результата после завершения.
- 04
GET /processed/{id}
Изображение возвращается из Redis как PNG, без постоянного файла на диске.
03 / SOURCE
Что проверено по исходникам
- Три HTTP-эндпоинта и разделение API/обработчика.
- Входные и выходные данные хранятся в Redis с TTL один час.
- В репозитории есть тест отсутствующего файла и тест полного пути с синхронным выполнением Celery.
- Docker Compose описывает Flask, Redis и Celery.
04 / LIMITS
Что нужно доработать
- Нет явного ограничения размера принимаемого файла и проверки содержимого по сигнатуре.
- max_retries=3 в декораторе Celery не означает автоматический повтор: self.retry в обработчике сейчас не вызывается.
- Нужны сценарии падения Redis, недоступного воркера, повреждённого файла и исчерпания TTL.
- Тесты обнаружены в коде, но при этом аудите не запускались. Публичное live-демо пока не обещаю.
05 / VERIFICATION
Где посмотреть доказательства
В репозитории: app.py, tasks.py, tests/test_api.py и docker-compose.yml. В тестах Celery переводится в eager-режим, поэтому это не проверка настоящей распределённой очереди.
Почему добавил проект
Он показывает другую сторону Python backend: работа с файлами, результатами долгих задач и ограниченным временем хранения.