selfpost/docs/plans/web-split.md

План: 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 ради косметики.

Смысл появляется, когда пакет начнёт расти: domain-admin и inbound-relay добавляют в него код — роль приносит авторизацию в каждый хендлер, входящий релей — отдельные страницы и хендлеры входящих доменов. Рефакторинг дешевле делать перед этим ростом, чем после.

Рекомендуемый порядок

web-split → domain-admin → inbound-relay (см. roadmap).

1. web-split — заложить структуру пакета (в т.ч. место под web/auth), пока нет сквозных правок от роли и новых inbound-хендлеров.
2. domain-admin — авторизация в каждом хендлере опирается на уже выбранную схему пакета.
3. inbound-relay — новый вертикальный срез; проще добавить в уже разрезанный пакет, чем рефакторить вместе с двумя предыдущими фичами.

Порядок рекомендация, не блокер.

Готово, когда

Решение принято осознанно в момент старта работ — либо пакет разрезан по выбранной схеме, либо зафиксировано, что он остаётся плоским. После разрезки: build/vet/test зелёные, поведение панели неизменно.

Риски

• Преждевременное разбиение — лишний внутренний API и churn без выгоды;
• откладывание до после роста — сложнее рефакторинг в перемешку с фичами.