Тестовое задание на позицию Fullstack разработчика (Python + React)

Вводные:

1. Здесь представлен MVP проект файлообменника. Он позволяет загружать файлы, проверяет их на подозрительный контент и отправляет алерты;
2. Репозиторий содержит в себе бэкенд и фронтенд части;
3. В обоих частях присутствуют баги, неоптимизированный код, неудачные архитектурные решения.

Задачи:

1. Проведите рефакторинг бэкенда, не ломая бизнес-логики: предложите свое видение архитектуры и реализуйте его;
2. (Дополнительно) На бэкенде есть возможность неочевидной оптимизации - выполните ее;
3. (Дополнительно) Разбейте логику фронтенда на слои;

Запуск:

1. docker compose -f docker-compose.dev.yml up
2. docker exec -it backend alembic upgrade head

Открыть фронт: http://localhost:3000/test

Открыть бэк: http://localhost:8000/docs

Решения при рефакторинге

Celery оставлен намеренно. Текущие проверки просты, и технически можно было бы обойтись FastAPI BackgroundTasks. Однако если предположить, что это эмуляция реального сканирования (ClamAV, VirusTotal), то Celery оправдан — задачи могут занимать секунды, и BackgroundTasks не даст retry-логики и независимого масштабирования воркеров

Ограничение архитектуры: Celery + async. Celery не поддерживает async def таски нативно, поэтому используется run_in_worker_loop с ручным управлением event loop. Это хрупкое решение — глобальный loop может закрыться неожиданно при перезапуске воркера. В продакшне стоит рассмотреть переход на gevent-воркеры: это позволит убрать бойлерплейт и объявлять таски напрямую как async def. Не реализовано, так как выходит за рамки рефакторинга

Статусные поля без Enum. processing_status, scan_status, level хранятся как строки без ограничений на уровне БД или Python. В идеале — Enum, чтобы исключить опечатки и гарантировать консистентность значений во всём коде. Не реализовано, так как требует миграции схемы БД, выходит за рамки рефакторинга