Комментарии 21
Наблюдаю за развитием этого проекта почти с самого его начала. Некоторое время назад попробовал один свой Angular SPA проект переписать на Blazor WebAssembley, локально казалось что все отлично, разочарование возникло когда выложил на сервер — очень долго загружается, в браузере в мониторинге загрузки посмотрел, грузятся все dll библиотеки, которых там на мегабайт 7, потом запускается приложение, также в настоящее время не работает в safari, как сказали в поддержке — это не их ошибка а ошибка в mono, ждут когда починят, отклик на кнопках гораздо медленнее чем например в Angular. Попробовал запустить проект также на Blazor Server — ещё хуже, для SPA он точно не подходит, очень большой трафик гоняется между клиентом и сервером, на совсем тяжёлых страницах постоянно обрывается коннекшн, очень медленный отклик. Вобщем понял, что для моих задач к сожалению он не подходит, вернулся к Angular.
Использую сервер-сайд Blazor в проекте. Специально посмотрел трафик через вебсокет.
Загрузка страницы с таблицей занимает 60кб. Загрузка следующей страницы в таблице — 20кб.
Я не могу сказать, что это совсем мало, но подключение в 1гбит/с сможет отдавать 2000+ страниц в секунду.
Кроме того, я не очень понимаю понятий тяжелых страниц для клиента в серверном блейзоре, ведь он серверный. Если вы не перегружаете всю страницу, то блейзор пересылает только куски изменившегося DOMа. Скорее всего, что-то делается не так.
Что касается клиентского блейзора, то тут следующие моменты:
1) Без сторонних библиотек последние разы была первая загрузка около 2.5Мб
2) Моно и библиотеки прекрасно кэшируются браузером
3) Майкрософт пилит триминг методов и классов из библиотек при сборке.
Лично я в своем проекте вижу следующие плюсы по сравнению с Ангуляром
1) Использование единых моделей/вью моделей. Тем самым нам не нужно думать о несоответствиях в WebAPI и Ангуляре. Конечно, можно настроить действие, которое перегенерит DAL в Ангуляре при сборке из сваггера, но это уже геморрой.
2) Удобная манипуляция данными. Мы можем выдавать спокойно IQueryable из сервиса, а UI компонент сам разберется с пейджингом, фильтрами и прочим. Это экономит тучу времени на разработке.
3) Использование .Net инфраструктуры в браузере. Например выгрузка в Эксель.
4) Быстрая сборка. Чтобы там не говорили, но пересобирать проект вебпаком — это боль.
В итоге мы просто экономим кучу времени на всяких мелочах, и получаем результат быстрее.
Загрузка страницы с таблицей занимает 60кб. Загрузка следующей страницы в таблице — 20кб.
Я не могу сказать, что это совсем мало, но подключение в 1гбит/с сможет отдавать 2000+ страниц в секунду.
Кроме того, я не очень понимаю понятий тяжелых страниц для клиента в серверном блейзоре, ведь он серверный. Если вы не перегружаете всю страницу, то блейзор пересылает только куски изменившегося DOMа. Скорее всего, что-то делается не так.
Что касается клиентского блейзора, то тут следующие моменты:
1) Без сторонних библиотек последние разы была первая загрузка около 2.5Мб
2) Моно и библиотеки прекрасно кэшируются браузером
3) Майкрософт пилит триминг методов и классов из библиотек при сборке.
Лично я в своем проекте вижу следующие плюсы по сравнению с Ангуляром
1) Использование единых моделей/вью моделей. Тем самым нам не нужно думать о несоответствиях в WebAPI и Ангуляре. Конечно, можно настроить действие, которое перегенерит DAL в Ангуляре при сборке из сваггера, но это уже геморрой.
2) Удобная манипуляция данными. Мы можем выдавать спокойно IQueryable из сервиса, а UI компонент сам разберется с пейджингом, фильтрами и прочим. Это экономит тучу времени на разработке.
3) Использование .Net инфраструктуры в браузере. Например выгрузка в Эксель.
4) Быстрая сборка. Чтобы там не говорили, но пересобирать проект вебпаком — это боль.
В итоге мы просто экономим кучу времени на всяких мелочах, и получаем результат быстрее.
Лично я в своем проекте вижу следующие плюсы по сравнению с Ангуляром
Именно по этим причинам которые Вы указали и хотел перейти на Blazor, когда переносил проект — в разы скорость разработки быстрее получилась чем на Angular.
2) Моно и библиотеки прекрасно кэшируются браузером
Это да, но вот первой загрузки клиент может и не дождаться, через 5-10 секунд решит что сервис не работает.
Сейчас померил скорость загрузки, на не очень быстром мобильном интернете — 14 секунд, передано 12Мб.
Однако если вам требуется поддержка старых браузеров без поддержки WebAssembly, то Blazor WebAssembly не для вас.
Интересный способ сказать «IE11».
Мне показалось или нет, что Blazor Server это реинкарнация ASP WebForms? принципы похожи очень.
Очень хочется попробовать Blazor Hybrid и Blazor Native для создание кроссплатформенных приложений.
На самом деле не получиться сразу взять и запустить код, который был написан на Blazor Server как приложение Blazor WebAssembly. Дело в том, что Blazor WebAssembly работает на клиенте и не сможет просто так обращаться к EF контексту, поэтому все манипуляции с данными лучше всего изначально делать через какой-то интерфейс, который будет на Blazor Server реализован через DBContext, а в WebAssembly, например, через Http.GetJsonAsync<>().
Ну и аутентификация у них как минимум будет по разному работать.
Ну а сами UI компоненты в общем-то могут быть одинаковыми и их вообще можно выносить в отдельный проект и паковать в nuget пакеты.
Ну и аутентификация у них как минимум будет по разному работать.
Ну а сами UI компоненты в общем-то могут быть одинаковыми и их вообще можно выносить в отдельный проект и паковать в nuget пакеты.
sahsAGU, Подскажите, Аутентификация в Blazor Server работает через отдельный http запрос к контроллеру или можно это сделать внутри обработчика нажатия кнопки в RazorComponent'е?
В примерах MSDN, я видел решение такое: пользователь открывает отдельную страницу, на которой отображается классическая форма, которая отправляет данные в контроллер, а в контроллере создается экземпляр ClaimsPrincipal, который передается методу HttpContext.SignInAsync(claims).
Проблема в том, что у Blazor какой-то особенный HttpContext, который не содержит такого метода, т.е. в компоненте можно прочитать имя авторизованного пользователя, а вот установить его не получается, хотя это странно — это же серверный код.
В примерах MSDN, я видел решение такое: пользователь открывает отдельную страницу, на которой отображается классическая форма, которая отправляет данные в контроллер, а в контроллере создается экземпляр ClaimsPrincipal, который передается методу HttpContext.SignInAsync(claims).
Проблема в том, что у Blazor какой-то особенный HttpContext, который не содержит такого метода, т.е. в компоненте можно прочитать имя авторизованного пользователя, а вот установить его не получается, хотя это странно — это же серверный код.
С контекстом все просто. Его нельзя установить, так как нет http вызовов, ведь мы общаемся через веб сокеты.
В своём текущем проекте, в рамках сессии, я просто реализовал свой сервис аутентификации (дергаю AD получаю юзера и роли). Не использую отдельных апи для авторизации.
Тут желательно бы реализовать хранение токена в локал сторейдже, но я пока не решил архитектурную проблему где писать в сторейдж. Все хорошо работает в коде рейзор страницы, но совсем не очень в сервисах. А токен надо бы писать именно в сервисе.
П.С. Можно реализовать установку куки в отдельном Api, как в примерах. Оно работает, но тут своя проблема. В примерах Гет метод, а это совсем плохо, пароли в открытом виде куда-то ходят. Надо бы минимум на пост переделывать. А за пять минут у меня пост метод написать не получилось.
В своём текущем проекте, в рамках сессии, я просто реализовал свой сервис аутентификации (дергаю AD получаю юзера и роли). Не использую отдельных апи для авторизации.
Тут желательно бы реализовать хранение токена в локал сторейдже, но я пока не решил архитектурную проблему где писать в сторейдж. Все хорошо работает в коде рейзор страницы, но совсем не очень в сервисах. А токен надо бы писать именно в сервисе.
П.С. Можно реализовать установку куки в отдельном Api, как в примерах. Оно работает, но тут своя проблема. В примерах Гет метод, а это совсем плохо, пароли в открытом виде куда-то ходят. Надо бы минимум на пост переделывать. А за пять минут у меня пост метод написать не получилось.
Это как то странно выглядит. У нас нет http вызова, но мы все равно обращаемся к серверу, пусть даже и через сокеты. Почему бы серверу внутри этого обращения не назначить контексту реквизиты безопасности? эта операция все равно выполняется на сервере. Кроме того, для поддержки контекста используется куки и SessionId, внутри них, а он при первом соединении генерируется и сохраняется на клиенте. В общем, это выглядит каким-то искусственным ограничением.
С чего вдруг это операция выполняется на сервере? Весь смысл в том, что именно на клиенте в куках или в локал сторейдже хранятся токены. Именно они кладутся в реквесты. И именно на основе них сервер определяет, что это пользователь именно я.
Когда сервер «ставит» куки, он возвращает сет куки клиенту, и браузер их устанавливает.
Соответственно, если нет реквестов/респонсов, нет и куки. А в сигнал Р их и нет. Там нужно это делать как-то через JS introp или отдельным HTTP запросом на эндпоинт. Проблема в том, что у меня в сервисе ауса, который я написал, не получается установить значение в локал сторейдж. Когда все прогрузилось — легко. А вот в сам момент не получается. Может я просто кривой.
Когда сервер «ставит» куки, он возвращает сет куки клиенту, и браузер их устанавливает.
Соответственно, если нет реквестов/респонсов, нет и куки. А в сигнал Р их и нет. Там нужно это делать как-то через JS introp или отдельным HTTP запросом на эндпоинт. Проблема в том, что у меня в сервисе ауса, который я написал, не получается установить значение в локал сторейдж. Когда все прогрузилось — легко. А вот в сам момент не получается. Может я просто кривой.
ждём react.net :)
Не совсем то, но уже можно писать desktop приложения с помощью react фреймворка GitHub
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сценарии использования и производительность Blazor Server в .NET Core 3.0