Split detailed design into docs/plans/ and keep roadmap as a status index; align product, development, and README with the 1.x+ release line. Co-authored-by: Cursor <cursoragent@cursor.com>
2.3 KiB
План: web-split (разбиение internal/web)
Статус: согласовано
Версия: 1.x; внутренний рефакторинг, сам по себе breaking не тянет.
Что это
internal/web — самый крупный пакет проекта: ~50 файлов (включая шаблоны и
static), ~25 .go / ~4000 строк Go, в одной плоскости лежат хендлеры всех
разделов панели, сессии, security-заголовки, проверка Origin, валидация форм и
рендер шаблонов.
Кандидаты на выделение — web/handlers и web/auth, либо разрез по доменам
панели.
Почему сейчас
На нынешнем размере плоский пакет читается: имена файлов (handlers_domains.go,
handlers_apps.go, handlers_monitor.go) работают не хуже каталогов, а
разбиение потянуло бы за собой экспорт того, что сейчас пакетно-приватно, — то
есть расширение внутреннего API ради косметики.
Смысл появляется, когда пакет начнёт расти: inbound-relay и domain-admin добавляют в него код — роль приносит авторизацию в каждый хендлер, входящий релей — отдельные страницы и хендлеры входящих доменов. Рефакторинг дешевле делать перед этим ростом, чем после.
Готово, когда
Решение принято осознанно в момент старта работ — либо пакет разрезан по
выбранной схеме, либо зафиксировано, что он остаётся плоским. После разрезки:
build/vet/test зелёные, поведение панели неизменно.
Риски
- Преждевременное разбиение — лишний внутренний API и churn без выгоды;
- откладывание до после роста — сложнее рефакторинг в перемешку с фичами.