Endge

Тема

Health checks и статус платформы ​

Одна потребность: платформа и приложения должны явно проверять доступность зависимостей (API, бэкенд, интеграции) и показывать пользователю и оператору понятный статус «работает / деградация / недоступно», вместо «белого экрана» или неочевидных ошибок.

Зачем это нужно (мировой опыт) ​

  • Kubernetes, cloud-native: readiness/liveness probes решают, направлять ли трафик на инстанс и перезапускать ли контейнер. Без них оркестратор не отличает «завис» от «занят».
  • AWS, GCP, Azure: сервисы предоставляют health endpoints; мониторинг и алертинг опираются на них.
  • Enterprise Low-Code (OutSystems, Mendix, ServiceNow): платформа и приложения имеют статус-страницы, проверку подключения к БД и к внешним сервисам; при деградации показывается сообщение, а не падение.
  • SRE-практики: один из золотых сигналов — доступность (availability); health check — минимальный контракт для её измерения.

Текущее состояние ​

  • На фронте нет единой проверки «доступен ли API» при старте приложения или периодически. При недоступном бэкенде пользователь может увидеть бесконечный спиннер, ошибки в консоли или разрозненные сообщения об ошибках.
  • В app-render-guard при фатальной ошибке рендера выполняется сброс состояния (localStorage, EndgeAdmin), но это не «проверка здоровья» сервисов.
  • Роутер и bootstrap не проверяют явно доступность API перед переходом на защищённые страницы; при падении запроса auth или данных — обработка через общий catch и toast/ErrorView.
  • Бэкенд (Payload, будущий Go-сервис) в roadmap упоминает «readiness/liveness с зависимостями (DB, cache, queue)» — на фронте нужен симметричный контракт: что вызывать и как интерпретировать ответ.

Что сделать ​

1. Backend: health endpoints ​

  • Readiness: «готов ли инстанс принимать трафик» — проверка БД, кэша, критичных интеграций. Возврат 200 при успехе, 503 при неготовности.
  • Liveness: «жив ли процесс» — минимальная проверка без внешних зависимостей. Используется оркестратором для рестарта.
  • Документировать URL (например, GET /api/health/ready, GET /api/health/live) и формат ответа (JSON с полями status, checks, version при необходимости).

2. Frontend: проверка при старте и при необходимости периодически ​

  • При инициализации приложения (до или сразу после bootstrap) выполнять запрос к readiness (или к «легкому» endpoint типа GET /api/health). При неуспехе — не переходить на основной UI, а показывать экран «Сервис временно недоступен» с кнопкой «Повторить» и опционально контактами поддержки.
  • Опционально: периодическая проверка (например, раз в N секунд) для длинных сессий; при переходе из «доступен» в «недоступен» — показать баннер или модал «Потеряно соединение с сервером», не роняя уже открытые экраны.
  • Использовать тот же таймаут и retry-политику, что и для обычных API (или мягче), чтобы не блокировать старт надолго при медленной сети.

3. Единый контракт и слой ​

  • Выделить модуль/сервис «platform health» (или расширить конфигурацию/диагностику): функция checkHealth() возвращает Promise с результатом HealthStatus; приложение вызывает её при старте и при необходимости по таймеру.
  • Статус «доступен / деградация / недоступен» хранить в реактивном состоянии и использовать для отображения экрана-заглушки или баннера.
  • Интеграция с диагностикой: при смене статуса писать событие в Endge.diagnostics (канал health) для логов и алертинга.

4. Отображение для пользователя ​

  • Экран «Сервис недоступен»: короткий текст, кнопка «Повторить» (повторный вызов health), при необходимости ссылка на статус-страницу или поддержку.
  • Не показывать технические детали (стек, URL) обычному пользователю; при необходимости передавать код/идентификатор в поддержку.

Риски и ограничения ​

  • Health check при старте добавляет задержку (таймаут); при медленной сети возможен ложный «сервис недоступен». Нужен разумный таймаут и кнопка «Повторить». Зависимость от бэкенда: без readiness/liveness endpoints фронт может проверять только доступность одного «легкого» endpoint (например, GET /api/health).

Вывод ​

  • Ввести health endpoints на бэкенде (readiness/liveness) и единый слой проверки на фронте.
  • При старте и при необходимости периодически проверять доступность; при недоступности показывать понятный экран вместо белого экрана или разрозненных ошибок.
  • Связать с диагностикой и мониторингом для операторов.