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

MVP файлообменника: загрузка файлов → проверка на подозрительный контент → отправка алертов. Репозиторий отрефакторен без изменения бизнес-логики и публичного контракта API (единственное осознанное отклонение — поведение DELETE, см. ниже).

Сопроводительные документы

• AUDIT.md — все найденные проблемы (файл:строка, категория, серьёзность).
• ARCHITECTURE.md — целевая архитектура, обоснование решений и разбор неочевидной оптимизации (было → стало → эффект).

Запуск

cp .env.dev.example .env.dev   # локальные переменные окружения
docker compose -f docker-compose.dev.yml up
docker exec -it backend alembic upgrade head

• Фронт: http://localhost:3000/test
• Бэк (Swagger): http://localhost:8000/docs

Что сделано

• Бэкенд разбит на слои: core (конфиг + БД), storage, repositories, services, api (роутеры + DI), tasks, app factory. Единый конфиг на pydantic-settings и единый async-engine вместо разрозненного os.environ и дублирующихся движков.
• Неблокирующий I/O: потоковая запись загрузки и файловые операции через anyio.
• Неочевидная оптимизация: линейный конвейер scan → metadata → alert из трёх Celery-задач объединён в одну (1 обращение к брокеру / 1 сессия / 1 выборка записи вместо трёх).
• БД: индексы под сортировки и внешний ключ; ON DELETE CASCADE для алертов.
• Фронтенд: монолитный page.tsx разнесён на слои (types / api / hooks / components / utils).
• Надёжность и оснастка: жизненный цикл БД (lifespan + engine.dispose()), health-эндпоинт GET /health, линтер и форматтер ruff, тесты фронтенда (Vitest), CI (GitHub Actions) и pre-commit.
• Доработки по ревью: потоковое чтение метаданных (без загрузки файла целиком), пагинация /files и /alerts (limit/offset), retry фоновых задач с backoff, согласованность файла и БД (удаление файла после commit, очистка сироты при сбое).

Осознанное изменение поведения

DELETE /files/{id} для обработанного файла раньше падал с 500 (FK без каскада) — теперь возвращает 204 и каскадно удаляет алерты. Подробности — в ARCHITECTURE.md.

Структура бэкенда

backend/src/
├── core/          # config (pydantic-settings), database (engine, DI-сессия)
├── storage.py     # файловое хранилище (неблокирующий потоковый I/O)
├── exceptions.py  # доменные исключения
├── models.py      # ORM-модели
├── schemas.py     # Pydantic-DTO
├── repositories/  # доступ к данным (FileRepository, AlertRepository)
├── services/      # бизнес-логика (FileService, ProcessingService, AlertService)
├── api/           # тонкие роутеры + DI (deps, files, alerts)
├── tasks.py       # Celery-приложение и задача process_file
└── app.py         # create_app()

Тесты и линтинг

Бэкенд (pytest + httpx ASGI) — конвейер обработки, scan-правила и контракт API. Нужен запущенный Postgres (порт проброшен на localhost:5433); тесты используют отдельную БД test_pytest.

cd backend
uv sync --group dev
uv run ruff check src tests          # линтер
POSTGRES_HOST=localhost uv run pytest # тесты

Фронтенд (Vitest) — форматтеры и маппинг статусов:

cd frontend
npm install
npm test

CI прогоняет линт и оба набора тестов на каждый push/PR (.github/workflows/ci.yml).