Azure-net: an application framework on SvelteKit
Azure-net Kit is an opinionated application framework on top of SvelteKit. Svelte owns reactivity and components; SvelteKit owns routes and SSR; Kit connects application lifecycle, request-local dependencies, typed delivery and infrastructure.
The framework is useful when a frontend grows beyond pages that call fetch: several business areas, shared infrastructure, public/account/admin interfaces, forms, localization and user-specific SSR state. It does not require a microservice backend or a separate repository for each context.
Three packages, three responsibilities
| Package | Responsibility | Start here |
|---|---|---|
@azure-net/kit | Application lifecycle, DI, presenters, schema validation, HTTP, reactive helpers and built-in translations | Architecture |
@azure-net/cli | Generate the architecture and check its boundaries; development dependency | CLI |
@azure-net/ui-kit | Svelte UI components, modal/notification managers, slider, cropper and browser interactions | UI-kit |
UI-kit is optional. CLI does not run in your browser. Kit re-exports @azure-net/tools through @azure-net/kit/tools; Edges and the old standalone translations package are not prerequisites for the current architecture.
Read in this order
- Architecture: distinguish business contexts from application boundaries.
- Contexts and aggregates: place contracts, models, repositories and use cases.
- Composition and DI: assemble concrete implementations without coupling consumers to classes.
- Presentation: organize scopes, presenters and state.
- Installation, bootstrap and translations.
- API reference and recipes while implementing features.
Scope and guarantees
These pages describe the local 6.x API line, including pre-release APIs. Examples target SvelteKit 3 and Svelte 5; use matching package versions and verify the package's peer dependencies when upgrading. Architecture checks are useful guardrails, not a proof of business correctness or an authorization system.
SSR isolation requires the plugin's request context and correct lifetimes. Register factories at module scope, resolve user-specific instances inside a request/component, and never store a user's mutable data in an unscoped module variable. A lazy factory defers construction; it does not automatically split the JavaScript bundle.