Комментарии 8
Если это неудобно мне во время разработки, то посетителю сайта будет хуже.
Вот эту логику я не очень понял.
Автор считает, что если его напрягает время сборки проекта в дев режиме, то с такими же или чуть меньше задержками столкнется и пользователь .
На go + templ через air приходится ждать компиляцию любой мелочи. При этом скорость ответа go приложения на проде неспоставима с "моментальным" php при разработке. При этом там в заголовке что-то про c# разработчика. Я ведь верно понял?
После прочтения статья оставляет какое-то ощущение обманутых ожиданий, даже по ссылке на оригинал сходил, чтобы убедиться, что статья свежая.
Blazor WebAssembly заставляет человека ждать, прежде чем что-то появится.
Основная “котлета” рантайма blazor wasm кешируется браузером, SSR уже давненько завезли, AOT компиляцию в нативный WASM, прочие оптимизации - в каждом релизе платформы. Неужели автор решил высказаться о технологии, о развитии которой не следит много лет?
Вакансий на Blazor я видел примерно ноль.
Кстати, уже где-то раза три за месяц на красном сайте натыкался на вакансии, хотя даже специально их не искал.
Вы описали Blazor в архитуктуре BFF, так как код компонентов рендерится на сервере, а не в браузере, поэтому для вашего API клиентом выступает сам Blazor, а не пользователь. Наилучший вариант пробросить ip пользователя через x-forwarded-for, что явно проще вашего способа (не нужно писать собственную функция для шифрования), но если использовать прокси-сервер, например от cloudflare или bunny (что для российского рынка сейчас привычнее), то используют ForwardedHeadersOptions
У меня была документация для чат бота на блазоре и она отлично индексировалась и грузилась быстро за счёт ssr. Правда я всё равно переделал её на реакт, а потом и на vue 3. Блазор так и не понял, хоть и c# мой первый язык, который выучил ещё в колледже.

Blazor против Vue.js: что замечает C#-разработчик