проектevasveltefrontend

Стеклянная панель для Евы: веб-интерфейс на Svelte Flow

· 2 мин · BadRabbit

У Евы есть веб-интерфейс, и у него одно главное правило: он ничего не решает. Это «стеклянная панель»: через неё видно, что происходит внутри, и можно поставить задачу, но ядро от интерфейса никак не зависит.

Почему так

Раньше UI жил прямо в репозитории ядра. Это быстро стало проблемой: сборка фронтенда тормозила сборку демона, а изменения в одном ломали другое. Я вынес интерфейс в отдельный репозиторий, Eva-Project-WebUI, и связал их только через публичный шлюз eva-api:

Браузер ⇄ eva-api (REST + SSE/WebSocket) ⇄ gRPC по Unix-сокету ⇄ ядро Eva

Следствие: интерфейс можно остановить, запустить на другой машине или вообще удалить, а ядро продолжит работать без UI и не потеряет ни байта контекста.

Что есть в интерфейсе

  • Чат с выбором маршрута: быстрый (Fast Track по готовому YAML-шаблону) или глубокий (Deep Track, где модели сами строят план).
  • Телеметрия: занятость VRAM и RAM, какие модели сейчас загружены, какие выгружены.
  • Монитор планировщика: живой граф задач (DAG) и очередь, отсортированная по WSJF. Видно, какой шаг сейчас выполняется и кто кого вытеснил.

Почему Svelte

Граф задач рисуется на Svelte Flow: узлы и рёбра, которые можно таскать и масштабировать. Сейчас интерфейс периодически опрашивает очередь планировщика, а следующим шагом станет поток событий. Svelte компилирует компоненты в точечные обновления DOM без виртуального DOM, и чем чаще будут приходить статусы, тем важнее это станет. Вечером будет разбор того, как работает реактивность в Svelte 5.

Стек: Svelte + Vite + TypeScript, Node 22 из flake.nix. Dev-сервер Vite проксирует запросы на eva-api:8080.

Что я понял

  1. Граница через API дисциплинирует. Как только у UI нет прямого доступа к внутренностям, приходится нормально проектировать внешний API. В итоге он же пригодится для CLI и других клиентов.
  2. Визуализация — это отладка. Узел, который десять секунд висит в «загрузке», на графе видно сразу, а в логах его ещё нужно найти.
  3. Headless-режим — нормальный режим. Сервисы, которые нужны человеку только иногда, не должны держать ядро в заложниках.