Данный проект реализует серверную часть для управления задачами и заказами на строительных объектах. Микросервисная архитектура обеспечивает стабильность, масштабируемость и удобство сопровождения. Проект строится в соответствии с техническим заданием, представленным в начале (см. раздел "Техническое задание").
Цель разработки:
- Реализовать backend-ядро для учёта пользователей, задач (заказов), единого входа через API-шлюз
- Повысить надёжность и безопасноcть (jwt, валидация, ограничение частоты, стандартизация ошибок, роли)
- Обеспечить запуск и тестирование инфраструктуры по docker-compose
- Приложить спецификацию API (OpenAPI/Swagger)
Основные компоненты:
api_gateway/— API-шлюз. Принимает все входящие запросы, проверяет JWT, проксирует обращения к соответствующим микросервисам. Ограничивает частоту, проводит CORS, стандартизирует ошибки, маршрутизирует пользователей и заказы.service_users/— Микросервис пользователей. Отвечает за регистрацию, аутентификацию (JWT), обновление и просмотр профиля, просмотр списка пользователей для админов.service_orders/— Микросервис заказов. Оперирует заказами: создание, просмотр, изменение статуса, получение списков. Проверяет права на каждое действие.docs/— API-спецификации (OpenAPI/Swagger).
Связь между сервисами через docker-сеть, переменные окружения, http-запросы:
КЛИЕНТ
|
v
[API Gateway] <----> [service_users]
|
+-------> [service_orders]
|
+-------> [PostgreSQL (бд общая)]
Все обращения к данным идут через шлюз (кроме административных или внутренних запросов).
- Строгое разделение ролей: инженер (создаёт дефекты), менеджер (назначает, проверяет), руководитель/заказчик - админы (отчетность)
- Все защищённые эндпойнты требуют авторизацию (Bearer/JWT)
- Логика жизненного цикла заказа, ролей и прав полностью соответствует ТЗ
- Любой ответ системы — типовой:
{success, data, error}. Ошибки формализованы (code,message) - Валидация полей и ограничение повторной регистрации (400 Bad Request)
- Каждый сервис можно масштабировать/заменять по отдельности
- Контейнеризация и сквозной запуск (разработка, тест, прод)
- Все инструкции, спецификации и примеры покрывают ключевые user story из ТЗ
- Проверьте установку Docker и WSL2. См. подробную инструкцию в файле
wsl-docker-install.mdв корне репозитория. - Перейдите в каталог проекта:
cd /mnt/c/Users/<Имя_пользователя>/ControlSys
- Запустите все сервисы:
docker compose up -d --build
- Проверьте логи (по желанию):
docker compose logs api_gateway docker compose logs service_users docker compose logs service_orders
- Тестирование (по желанию):
docker-compose exec api_gateway pytest tests/ -v - Проверьте работу API:
- Зайдите на: http://localhost:8000/health (статус шлюза)
curl http://localhost:8000/v1/profile(требует JWT)
Swagger/OpenAPI спецификация находится в директории docs/.
Документация с примерами доступна по адресу:
- http://localhost:8000/docs (если поддерживается FastAPI)
Тест-кейсы и сценарии:
- Регистрация пользователя:
POST /v1/register - Повторная регистрация — ошибка 400
- Вход —
POST /v1/login-> получение JWT - Получение/обновление профиля —
GET/PUT /v1/profile - Создание заказа —
POST /v1/orders - Получение и изменение заказа —
GET /v1/orders/{id}PATCH /v1/orders/{id}/status
Для тестирования: используйте Postman (есть готовая коллекция) или curl, либо автотесты в папках tests/
- Проект реализует только серверную часть, фронтенд не входит
- Заданные в ТЗ требования реализованы явно: маршрутирование, права, профили, обработка ошибок, роли
- Уровень "стандартной корпоративной надежности": описаны healthcheck, поддержка ошибок и ролей, структура логинов, разделение контейнеров