Azure-net: фреймворк приложения поверх SvelteKit
Azure-net Kit — фреймворк с определёнными архитектурными соглашениями поверх SvelteKit. Svelte отвечает за компоненты и реактивность, SvelteKit — за маршруты и SSR, а Kit связывает жизненный цикл приложения, зависимости запроса, типизированный delivery-слой и инфраструктуру.
Он полезен, когда фронтенд перерастает страницы с вызовами fetch: появляются бизнес-области, общая инфраструктура, публичный интерфейс/кабинет/админка, формы, локализация и пользовательское SSR-состояние. Для этого не нужны микросервисы на бэкенде или отдельный репозиторий для каждого контекста.
Три пакета — три задачи
| Пакет | Ответственность | С чего начать |
|---|---|---|
@azure-net/kit | Жизненный цикл, DI, презентеры, схемы валидации, HTTP, реактивные утилиты и встроенные переводы | Архитектура |
@azure-net/cli | Генерация архитектуры и проверка её границ; dev-зависимость | CLI |
@azure-net/ui-kit | Svelte-компоненты, менеджеры модалок/уведомлений, слайдер, кроппер и браузерные взаимодействия | UI-kit |
UI-kit необязателен. CLI не выполняется в браузере. Kit реэкспортирует @azure-net/tools через @azure-net/kit/tools; Edges и старый отдельный пакет переводов не нужны для актуальной архитектуры.
Порядок знакомства
- Архитектура: бизнес-контексты и границы интерфейса приложения — разные вещи.
- Контексты и агрегаты: размещение контрактов, моделей, репозиториев и юзкейсов.
- Композиция и DI: сборка реализаций без привязки потребителя к конкретному классу.
- Presentation: scopes, презентеры и состояние.
- Установка, bootstrap и переводы.
- API и рецепты по мере разработки.
Область применения и гарантии
Эти страницы описывают текущую локальную линейку API 6.x, включая предварительные версии. Примеры рассчитаны на SvelteKit 3 и Svelte 5; используйте совместимые версии пакетов и сверяйте peerDependencies при обновлении. Архитектурные проверки — полезные ограничения, но не доказательство корректности бизнес-логики и не система авторизации.
Изоляция SSR требует контекста запроса плагина и правильных жизненных циклов. На уровне модуля регистрируйте фабрики, пользовательские экземпляры получайте внутри запроса/компонента. Не храните изменяемые данные пользователя в общей переменной модуля. Ленивая фабрика откладывает создание объекта, но не разбивает JavaScript-бандл автоматически.