145 lines
8.1 KiB
Markdown
145 lines
8.1 KiB
Markdown
# Запрос к Claude (Sonnet): архитектурный аудит app-autotest v1.0.89
|
||
|
||
> **Цель**: получить анализ текущей архитектуры и рекомендации по развитию проекта.
|
||
> **Дата**: 27.07.2026
|
||
> **Версия**: 1.0.89
|
||
|
||
---
|
||
|
||
## 1. О проекте
|
||
|
||
### Что делает
|
||
Flask-приложение для ручного тестирования операций облачной платформы Nubes:
|
||
- CREATE — создать инстанс сервиса с параметрами
|
||
- MODIFY — изменить параметры существующего инстанса
|
||
- DELETE / SUSPEND / RESUME / REDEPLOY — управление инстансом
|
||
|
||
### Как работает сейчас
|
||
- Один HTML-файл (index.html) с ванильным JS — без фреймворков, без SPA
|
||
- Бэкенд: Flask + gunicorn (несколько воркеров)
|
||
- Все данные — из REST API Nubes (никакого локального кеша, кроме краткосрочного трекера)
|
||
- Трекер инстансов: JSON-файлы в /tmp/ под fcntl.flock
|
||
- Автоопределение стенда (dev/test) по JWT-токену
|
||
|
||
### Текущая файловая структура
|
||
```
|
||
app-autotest/
|
||
├── site/
|
||
│ ├── app.py ← Flask(__name__), blueprints, /health
|
||
│ ├── api/
|
||
│ │ └── http_client.py ← HttpClient, автостенд
|
||
│ ├── operations/
|
||
│ │ ├── get_params.py ← слияние state.params + шаблон
|
||
│ │ ├── get_services.py ← API-обёртки
|
||
│ │ ├── get_instances.py ← пагинация
|
||
│ │ └── tracker.py ← /tmp/instances-{clientId}-{stand}.json
|
||
│ ├── routes/
|
||
│ │ ├── main.py ← GET/POST /, /api/operations/<svc_id>
|
||
│ │ ├── api.py ← [LEGACY] раннер тестов
|
||
│ │ └── api_test.py ← /api/test, /api/params, /api/log
|
||
│ ├── templates/
|
||
│ │ └── index.html ← весь UI (~400 строк)
|
||
│ └── static/
|
||
│ └── style.css
|
||
├── DOCS/
|
||
│ ├── ARCHITECTURE.md ← актуальная архитектура
|
||
│ ├── ARCHITECTURE.legacy.md ← старая версия
|
||
│ ├── HISTORY.md ← история версий
|
||
│ └── ... ← 12+ legacy-документов
|
||
└── secrets/ ← токены (не в git)
|
||
```
|
||
|
||
### Ключевые детали реализации
|
||
- **Multi-worker safety**: все общие данные в /tmp/ под fcntl.flock
|
||
- **CREATE vs non-CREATE**: раздельные потоки в бэкенде и фронтенде
|
||
- **Текущие значения параметров**: GET /instances/{uid} → state.params + GET /instanceOperations/default/{opId} → слияние
|
||
- **Логирование**: /tmp/app-autotest.log + /api/log + скрытая UI-панель
|
||
- **Валидация**: HTML-escape + JSON-валидация map-полей (onblur + pre-submit)
|
||
|
||
---
|
||
|
||
## 2. Что нужно проанализировать
|
||
|
||
### A. Decoupling и модульность
|
||
Сейчас всё в одном HTML и одном api_test.py (300+ строк). Нужны рекомендации:
|
||
- Как разбить index.html на компоненты/модули?
|
||
- Как разбить api_test.py на независимые модули по операциям?
|
||
- Стоит ли переходить на микро-фронтенд (HTMX, Alpine.js, что-то ещё) или оставить ванильный JS?
|
||
- Как организовать роутинг если добавится больше страниц?
|
||
|
||
### B. Хранение данных тестов
|
||
Сейчас никакие результаты тестов не сохраняются. Нужно:
|
||
- Где и как хранить историю запусков (каждый запуск = запись)?
|
||
- Какие данные сохранять: параметры, длительность, статус, этапы, ошибки?
|
||
- Формат хранения: SQLite? JSON-файлы? Внешняя БД?
|
||
- Как привязать к конкретному инстансу и пользователю?
|
||
- Нужна ли страница истории/отчётов?
|
||
|
||
### C. Оптимизация для развития
|
||
- Что мешает добавить второй сервис (сейчас только Болванка, svcId=1)?
|
||
- Как сделать конфигурацию сервисов (какие сервисы показывать, какие операции)?
|
||
- Нужен ли config.yaml или всё из API?
|
||
- Как масштабировать на множество пользователей (изоляция данных)?
|
||
|
||
### D. Улучшения архитектуры
|
||
- Сейчас _client() определяется в двух местах (main.py и api_test.py) — как унифицировать?
|
||
- Стоит ли вынести общие хелперы (_client_id, _stand, _token_info) в отдельный модуль?
|
||
- Нужен ли middleware для токена (вместо ручного извлечения в каждом роуте)?
|
||
- Как улучшить обработку ошибок (сейчас много try/except с голым str(e))?
|
||
|
||
### E. Безопасность
|
||
- Токен передаётся в cookie и форме — достаточно ли этого?
|
||
- Нужна ли CSRF-защита для POST-запросов?
|
||
- Логи могут содержать чувствительные данные?
|
||
|
||
---
|
||
|
||
## 3. Ожидаемый формат ответа
|
||
|
||
### 1. Общая оценка
|
||
- Что сделано хорошо
|
||
- Что требует внимания
|
||
- Критические проблемы (если есть)
|
||
|
||
### 2. Decoupling — план
|
||
- Пошаговый план разбиения на модули
|
||
- Рекомендации по фронтенду (ванильный JS / HTMX / Alpine / SPA)
|
||
- Рекомендации по бэкенду (структура модулей)
|
||
|
||
### 3. Хранение данных тестов — план
|
||
- Схема данных (какие поля, какие таблицы/файлы)
|
||
- Технология (SQLite / PostgreSQL / JSON-файлы)
|
||
- API для чтения/записи
|
||
- UI для просмотра истории
|
||
|
||
### 4. Оптимизация — конкретные шаги
|
||
- Приоритизированный список улучшений
|
||
- Что можно сделать быстро, что требует переписывания
|
||
|
||
### 5. Риски и ограничения
|
||
- Что может пойти не так при предлагаемых изменениях
|
||
- Ограничения платформы (gunicorn, /tmp/, DDoS-Guard)
|
||
|
||
---
|
||
|
||
## 4. Файлы для изучения
|
||
|
||
**Код (в порядке важности):**
|
||
1. `site/routes/api_test.py` — основной модуль операций
|
||
2. `site/templates/index.html` — весь фронтенд
|
||
3. `site/routes/main.py` — главная страница и API операций
|
||
4. `site/api/http_client.py` — HTTP-клиент и автостенд
|
||
5. `site/operations/get_params.py` — слияние параметров
|
||
6. `site/operations/tracker.py` — файловый трекер
|
||
7. `site/app.py` — точка входа
|
||
8. `site/operations/get_services.py` + `get_instances.py` — API-обёртки
|
||
|
||
**Документация:**
|
||
1. `DOCS/ARCHITECTURE.md` — актуальная архитектура
|
||
2. `DOCS/HISTORY.md` — история версий
|
||
3. `DOCS/terraform-operations-full-logic.md` — логика API из Terraform-провайдера
|
||
|
||
**Данные (HAR-файлы):**
|
||
1. `development/dummycreate.har` — полный flow CREATE
|
||
2. `development/dummymodify.har` — полный flow MODIFY
|