dc-observatio/docs/план-перевода-с-pcp-ui-service.md

План перевода запросов с pcp-ui-service на источники

Составлено: 2026-06-10. Связано с задачей #40 бэклога бэклог-pcp-tgu-ops-ui.md.

Зачем

pcp-ui-service — наследие старого server-rendered UI (Thymeleaf-страницы + REST-прокси-обвязка над доменными сервисами). Новый фронт pcp-tgu-ui-service ходит к бэкендам через pcp-gateway-service, и большинство его клиентов уже бьют в доменные сервисы напрямую (/api/pcp-tgu, /api/pcp-mission, /api/pcp-ballistics, /api/pcp-complex, /api/pcp-request). pcp-ui-service остаётся в маршрутизации только как catch-all (ui-catch-all, order:1 в config-repo/pcp-gateway-service.yaml) для двух поверхностей. Цель — увести эти две поверхности на источники и вывести pcp-ui-service из эксплуатации.

Кто ещё зависит от pcp-ui-service

Проверено (grep по config-repo/, services/, libs/): никто, кроме фронта и catch-all gateway. Остальные ссылки — это самопрописка сервиса в Spring Boot Admin (config-repo/pcp-ui-service.yaml) и комментарии в pcp-types-lib про то, что обогащение DTO «исторически делалось в ui-service». Восток-запад (межсервис) сервис не вызывает никто.

Карта запросов фронта, идущих через pcp-ui-service

Через catch-all pcp-ui-service сейчас проходят запросы только из двух файлов фронта. Всё остальное (ballisticsApi, complexPlanApi, missionPlanningApi, requestApi, tguPlanApi, stationsApi) уже ходит мимо ui-service.

1. src/api/tguApi.ts → /api/tgu-planning/* (+ flight-line)

Контроллер TguPlanningRestController (services/pcp-ui-service/.../controller/TguPlanningController.kt) проксирует через TguPlanningService/BallisticsService. Источники и реальные пути:

Запрос фронта (через ui-service)	HTTP	Реальный источник	Путь на источнике
/api/tgu-planning/platforms	GET	pcp-tgu-service	/api/platforms
/api/tgu-planning/plans?historyDays	GET	pcp-tgu-service	/api/plans?historyDays
/api/tgu-planning/spacecraft/{id}/plans?historyDays	GET	pcp-tgu-service	/api/plans/{spacecraftId}?historyDays
/api/tgu-planning/plans/{planId}/decision?decision&reason	POST	pcp-tgu-service (TEST)	/test/tgu/plans/{planId}/decision
/api/tgu-planning/plans/{planId}/dismiss	POST	pcp-tgu-service	/api/plans/{planId}/dismiss
/api/tgu-planning/plans/{planId}/restore	POST	pcp-tgu-service	/api/plans/{planId}/restore
/api/tgu-planning/plans/{planId}/confirm-layin?reason	POST	pcp-tgu-service (TEST)	/test/tgu/plans/{planId}/confirm-layin
/api/tgu-planning/spacecraft/{noradId}/flight-line	GET	pcp-ballistics-service	/api/satellites/{noradId}/flight-line (+интервал)

Что ui-service делает поверх прокси (нельзя потерять при переезде):

• Перевод ошибок в человекочитаемые сообщения для решения по плану (decision): 404 → «План не найден.» / «Test controller недоступен или отключён.»; 409 → «План не является активным планом, ожидающим решения…»; 5xx → «Test controller недоступен…». Сетевые сбои (WebClientRequestException) → 503 «Test controller недоступен…». При переезде эту UX-обвязку нужно перенести во фронт (tguApi.ts/общий http.ts, см. #17), иначе оператор увидит сырой 4xx/5xx.
• decision и confirm-layin идут в тест-контроллер tgu (/test/tgu/...), гейтится tgu.test-controller.enabled в config-repo/pcp-tgu-service.yaml. Это MVP-канал подтверждений (ср. #13). При переезде поведение не меняется — но прод-канал решений остаётся отдельным вопросом.
• DTO (TguPlanResponse, TguPlatformResponse) проксируются как есть (bodyToFlux того же типа) — форма ответа источника и ui-service идентична, фронт не сломается по схеме.

2. src/features/tgu-editor/editorApi.ts → /api/current-plans/missions/{planId}/modes

Запрос фронта (через ui-service)	HTTP	Реальный источник	Путь на источнике
/api/current-plans/missions/{planId}/modes	GET	pcp-mission-planing-service	/api/missions/{missionId}/modes

CurrentPlansController.modes → MissionService.modesByMission → ${settings.mission-service} (= pcp.services.mission = pcp-mission-planing-service), прямой проброс List<ModeResponseDTO>. Фронтовый missionPlanningApi.ts уже ходит в этот же сервис через /api/pcp-mission — endpoint переезжает туда же.

План перевода (порядок шагов)

Статус (2026-06-10): шаги 1–7 выполнены — фронт ходит в источники напрямую, catch-all снят. Шаг 8 (вывод сервиса из эксплуатации) отложен до проверки репойнта на живом стенде; до этого pcp-ui-service остаётся задеплоен, но без маршрутов (безвреден). Перевод ошибок решения уже жил во фронте (errorMessage в tguApi.ts) — серверная обвязка ui-service дублировала его, при прямом обращении к tgu ничего не потеряно.

1. flight-line → /api/pcp-ballistics. Перенести fetchFlightLine в ballisticsApi.ts (там уже BASE=/api/pcp-ballistics), путь /api/satellites/{noradId}/flight-line + интервал time_start/time_stop. Сверить формат точек FlightLinePoint с тем, что отдаёт баллистика напрямую (ui-service отдавал collectList().block() того же flux — форма та же).
2. platforms / plans / spacecraft-plans → /api/pcp-tgu. Перепривязать GET-методы tguApi.ts на /api/pcp-tgu + /api/platforms, /api/plans, /api/plans/{id}. tguPlanApi.ts уже использует этот префикс — переиспользовать его конвенции/fetchJson.
3. dismiss / restore → /api/pcp-tgu на /api/plans/{id}/dismiss|restore (реальный API).
4. decision / confirm-layin → /api/pcp-tgu на /test/tgu/plans/{id}/decision|confirm-layin. Одновременно перенести во фронт перевод ошибок (карта статусов → сообщения выше). Учесть зависимость от tgu.test-controller.enabled.
5. modes → /api/pcp-mission. В editorApi.ts заменить /api/current-plans/missions/{id}/modes на /api/pcp-mission/api/missions/{id}/modes (через общий клиент/apiFetch). Свериться с missionPlanningApi.ts.
6. Vite/nginx. Проверить, что /api/pcp-* и /api/pcp-mission уже проксируются на gateway (да — единый /api → gateway). Спец-обработка /api/tgu-planning//api/current-plans не нужна.
7. Снять catch-all. Удалить маршрут ui-catch-all из config-repo/pcp-gateway-service.yaml (после того как фронт перестал слать /api/tgu-planning и /api/current-plans). Проверить, что никакой /api/** больше не должен попадать в ui-service.
8. Вывод сервиса из эксплуатации. Убрать pcp-ui-service из gateway-реестра-потребителей, docker-compose/helm/CI (.gitlab/ci/pcp-ui-service.yml, include в .gitlab-ci.yml, changes:-списки), config-repo/pcp-ui-service.yaml, Spring Boot Admin. Код сервиса — архивировать/удалить отдельным шагом после стабилизации.

Риски и на что смотреть

• Потеря UX-перевода ошибок решения — главный функциональный риск. Перенести в фронт вместе с шагом 4, не откладывать.
• Тест-контроллер как канал решений — decision/confirm-layin остаются на /test/tgu/*. Это сознательный MVP-срез; прод-канал — отдельная задача (ср. #13).
• Мёртвые поверхности ui-service. Контроллеры bookings, catalog, rva, dynamic-plan, tle-analysis, tle-comparison, com-plan, requests, map, satellites/pdcm, RvaController и server-rendered страницы новый фронт не вызывает — они умирают вместе с сервисом. Перед удалением кода ещё раз убедиться, что у них нет внешних потребителей (геопортал и т.п.).
• Обогащение DTO в ui-service (BookedSlotDetailsDTO: имя/тип КА добавлялись в ui-service). Если такая обогащённая поверхность понадобится новому фронту — она должна переехать в источник или во фронт, а не остаться «висеть» в умирающем сервисе. Сейчас новый фронт её не использует.