Blazor даёт три модели выполнения. Это не стилистические различия — они определяют где живёт память, как работает сеть и во сколько обходится масштабирование.
Interactive Server
C# выполняется на сервере, браузер — тонкий клиент. Между ними — постоянный WebSocket: каждое UI-событие летит на сервер, обратно возвращается только diff DOM.
Каждая открытая вкладка создаёт circuit в памяти сервера. 1000 пользователей — ~300 МБ только на состояние, 20 000 — уже серьёзная инфраструктура.
Зато можно инжектить DbContext прямо в компонент, не нужен API-слой, скорость разработки максимальная. Подходит для внутренних инструментов с небольшой аудиторией.
Interactive WebAssembly
Браузер скачивает .NET runtime и сборки приложения, C# выполняется локально. UI-события не уходят в сеть — отклик мгновенный.
Сервер становится stateless: только API и статика.
Первая загрузка тяжелее — от 2 до 10+ МБ в зависимости от сборок. И главное правило: никаких секретов в WASM, IL декомпилируется.
Вся авторизация и бизнес-логика — только за API. Хорошо масштабируется, дёшево хостится через CDN.
Interactive Auto
Гибридный режим: первый визит работает как Server — мгновенный рендер без ожидания загрузки WASM. Параллельно браузер скачивает рантайм, и при следующем визите компонент уже выполняется на клиенте.
Сложность в том, что один и тот же компонент должен уметь работать в обоих контекстах. Прямой
@inject AppDbContext сломается в браузере. Решение — общий интерфейс с двумя реализациями: серверной и клиентской. DI сам подставит нужную.
Как выбирать:
— небольшая внутренняя аудитория, нужна скорость разработки → Server
— публичный SaaS, много пользователей, важна стоимость хостинга → WebAssembly
— публичное приложение, важен SEO и первый paint, но нужна SPA-производительность → Auto
— сложный продукт с разными модулями → комбинируйте режимы под каждый раздел
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека шарписта
#sharp_view