Тестовое API для бронирования переговорок на FastAPI + SQLAlchemy + PostgreSQL.
Сервис поддерживает:
- получение тестового JWT через
/dummyLogin - создание переговорок
- создание расписания переговорки
- получение списка доступных слотов
- создание и отмену брони
- просмотр броней
- Python 3.12
- FastAPI
- SQLAlchemy 2
- Alembic
- PostgreSQL 15
- PyJWT
- pytest
В проекте приложение запускается через entrypoint.sh: при старте контейнера автоматически выполняется alembic upgrade head, затем поднимается uvicorn.
Запуск:
docker compose up --buildПосле старта:
- API:
http://localhost:8080 - PostgreSQL:
localhost:5432
Swagger:
http://localhost:8080/docs
Используется файл .env.
Обязательные переменные:
JWT_SECRET_KEY=...
DATABASE_URL=postgresql+asyncpg://room-booking:room-booking@localhost:5432/room-bookingДля Alembic используется синхронный URL из alembic.ini.
Создание миграции:
.venv/bin/alembic revision --autogenerate -m "message"Применение миграций:
.venv/bin/alembic upgrade headТекущая initial migration:
Unit-тесты сервисного слоя:
.venv/bin/python -m pytest tests/test_service.py -qИнтеграционные тесты API:
.venv/bin/python -m pytest tests/test_api.py -qПолный запуск:
.venv/bin/python -m pytest -qВажно:
- для
tests/test_api.pyдолжна быть доступна локальная PostgreSQL наlocalhost:5432иначе тесты будут skipped - интеграционные тесты пересоздают схему БД перед каждым тестом
GET /_infoPOST /dummyLoginGET /rooms/listPOST /rooms/createPOST /rooms/{roomId}/schedule/createGET /rooms/{roomId}/slots/listPOST /bookings/createGET /bookings/listGET /bookings/myPOST /bookings/{bookingId}/cancel
- базовый API по переговоркам, слотам и броням
- JWT-авторизация через тестовый
/dummyLogin - Alembic-миграции
- unit-тесты сервисного слоя
- интеграционные тесты на:
- создание переговорки → создание расписания → создание брони
- отмену брони пользователем
- автоприменение миграций при запуске контейнера
Проект находится в рабочем состоянии, но не полностью доведён до финального соответствия исходному ТЗ. На момент последнего обновления остаются зоны, которые требуют доработки:
- список всех броней пагинируется в сервисе после чтения данных, а не на уровне SQL
- защита от гонки при одновременном бронировании одного слота не усилена ограничением на уровне БД
- расписание сейчас материализуется слотами на ограниченный горизонт вперёд