docs: document session 2 — API testing, DELETE 404 fix, funcs-console, source for services

2026-03-21 07:31:23 +03:00
parent 50f24565ec
commit 37a50c23c0
3 changed files with 200 additions and 2 deletions
@@ -2,6 +2,59 @@

 ---

+## 2026-03-21 — Объединить sless_function и sless_service в единый пользовательский листинг
+
+### Контекст
+
+`/funcs/{namespace}` (web-консоль) показывал только `sless_function` ресурсы (Kind=Function).
+`sless_service` ресурсы (`pg-info`, `pg-table-reader`, `pg-table-writer`) были скрыты — пользователь не видел часть своих развёрнутых функций.
+
+Первоначальный вопрос: почему `https://sless.kube5s.ru/funcs/sless-ffd1f598c169b0ae` пуст?
+Ответ: там были `sless_service`, а не `sless_function` — их не рендерили.
+
+### Решение
+
+Пользователю всё равно какой тип ресурса лежит под капотом — для него это просто «функция».
+Объединить оба типа в один список с визуальным маркером типа:
+- `sless_function` → бейдж `job`
+- `sless_service` → бейдж `always-on`
+
+Добавить поля `Kind` и `URL` в `fnResponse`. `fetchAndRender` теперь делает два запроса:
+1. `GET /v1/namespaces/{ns}/functions` — sless_function (job-style)
+2. `GET /v1/namespaces/{ns}/services` — sless_service (always-on Deployment)
+
+Оба списка объединяются, фильтруются и сортируются единообразно.
+
+### Почему НЕ делаем единый endpoint на операторе
+Не усложняем оператор ради UI. Агрегацию делает funcs-service — он уже служит «фасадом» между браузером и оператором. Оператор остаётся строго CRUD.
+
+### Имплементация
+- `services/funcs/main.go`: `svcResponse`, объединение в `fetchAndRender`
+- `services/funcs/index.html`: `badge-kind-service/function`, счётчик типов
+- Коммит `683d728`, funcs-service `v0.2.1`
+
+---
+
+## 2026-03-21 — Добавить /services/{name}/source в оператор, не расширять proxySourceGet на API gateway
+
+### Контекст
+
+После объединения листинга возникла 404 при просмотре кода `sless_service` через web-консоль.
+`proxySourceGet` передавал запрос на `/functions/{fn}/source`, но оператор маршрута `/services/{fn}/source` не имел.
+
+### Варианты
+1. В операторе: один универсальный `/resources/{fn}/source?type=service|function` — усложнит роутинг, нарушит REST-конвенцию.
+2. В funcs-service: разветвлять URL по `kind` — но тогда funcs-service должен знать о внутренней топологии.
+3. **Выбранный**: добавить отдельный `GET /v1/namespaces/{ns}/services/{name}/source` в оператор — симметрично с `/functions/{name}/source`. funcs-service передаёт `?kind` параметр.
+
+### Почему так
+- Симметричность `/functions/…/source` и `/services/…/source` — интуитивный REST.
+- Никаких изменений в роутинге оператора — просто новый endpoint с той же логикой.
+- `GetServiceSource` — буквально `GetSource` с `Service` CRD вместо `Function`. 30 строк кода.
+- Коммит `50f2456`, оператор `v0.1.45`
+
+---
+
 ## 2026-03-20 — Merge: убрать sless_function как обязательный prerequisite для sless_job

 ### Контекст