Тут уже несколько раз упоминали Blazor, но всё время в контексте WebAssebly (Client-side blazor). А я вот попробовал сделать небольшой проект в серверном варианте, и это... охрененно. Как будто снова пишешь простое приложение, без клиент-серверных api на каждый чих, (почти) без Java-/Typescript, без разделения на слои. Говнокодишь, но говнокодишь стильно.
Для тех кто не в курсе: Серверный вариант Blazor загружает на клиенте небольшую библиотеку и открвывает WebSocket к приложению на сервере, которое обрабатывает все действия пользователя (или события сторонних компонентов), обновляет у себя виртуальный DOM и при необходимости отправляет набор изменений, которые нужно внести в веб-страницу. Фактически получается одно приложение со множеством клиентских интерфейсов — веб-терминал.
Из того что понравилось:
Нужно подписать веб-страницу (а точнее компонент) на RabbitMQ? Просто подписываешь, никакой организации пересылки сообщений клиенту — оно просто работает.
Нужен доступ к базе — просто берёшь и стучишься в базу, не делая промежуточных api и общих моделей — обычный LINQ-запрос.
И так всё что угодно, без создания api и заботы о его безопасности — всё общение с сервером происходит в рамках вебсокета.
И при этом вся та же идеалогия веб-компонентов, что и в ангуляре/реакте.
Из минусов:
Привязка сессии к приложению. Если приложение будет перезапущено, клиент не сможет переключиться на другой инстанс.
Потенциально из-за общения по вебсокетам на каждое действие клиента или сервера, при большом пинге будет достаточно тормознуто (имхо, "большой пинг" в данном случае — round trip > 300ms)
API Blazor'а ещё активно перетряхивают.
PS. Не то что бы совсем холиварная тема, но речь скорее не о технологии (Blazor), а идеологии (n-tier), так что пусть будет тут.
S>Для тех кто не в курсе: Серверный вариант Blazor загружает на клиенте небольшую библиотеку и открвывает WebSocket к приложению на сервере, которое обрабатывает все действия пользователя (или события сторонних компонентов), обновляет у себя виртуальный DOM и при необходимости отправляет набор изменений, которые нужно внести в веб-страницу. Фактически получается одно приложение со множеством клиентских интерфейсов — веб-терминал.
С одной стороны это так: да, и зарезервированная для одного View память, и возможные утечки — всё это может больно ударить.
Но:
1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом
2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.
T>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...
Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности.
Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
S>1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом S>2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.
любое stateless-приложение (тот же asp.net web api) без проблем скалируeтся на самом дешёвом железе
S>1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом
100k пользователей — это ни о чем в классических приложениях.
S>2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.
Не получит. Потому что там будет не UI стейт, а пользовательский стейт и/или данные. UI-стейт очень редко хранится на сервере. В случае, когда всё на сервере, включая UI, становится печально.
Но для внутренних продуктов это может быть очень удобной вещью.
T>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений... IB>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности. IB>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.
что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели
T>>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений... IB>>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности. IB>>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть. T>что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели
Ты заявил, что Blazor не подходит для высоконагруженных приложений.
Под высоконагруженными приложениями я понимаю большое количество одновременно работающих пользователей. Если так то я вообще не понимаю при чём здесь Blazor.
Я предположил, что под высоконагруженными приложениями ты принимаешь приложения с нагруженным (богатым) пользовательским интерфейсом. Здесь, уже применимо, то что я написал про производительность, как быстрый отклик приложения на действия пользователя.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
T>>>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений... IB>>>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности. IB>>>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть. T>>что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели
IB>Ты заявил, что Blazor не подходит для высоконагруженных приложений. IB>Под высоконагруженными приложениями я понимаю большое количество одновременно работающих пользователей. Если так то я вообще не понимаю при чём здесь Blazor. IB>Я предположил, что под высоконагруженными приложениями ты принимаешь приложения с нагруженным (богатым) пользовательским интерфейсом. Здесь, уже применимо, то что я написал про производительность, как быстрый отклик приложения на действия пользователя.
тогда ты меня неправильно понял, майкрософтовский блэйзор предлагает опцию, где рендеровка происходит на сервере (server-side), именно этот вариант и испробывал автор топика и мои комментарии были именно касательно этого мода, тут всё понятно: никакой высокой нагрузки при таком моде быть не может ни на какой платформе
кроме того, есть вариант, где рендеровка происходит на клиенте — это ближе к тому, что WebAssembly, но это другая песня: там пока проблемы со стартом, так как в первый раз нужно грузить .NET runtime, что может быть слишком медленно и поэтому неприемлимо для любых, даже корпоративных пользователей
T>тогда ты меня неправильно понял, майкрософтовский блэйзор предлагает опцию, где рендеровка происходит на сервере (server-side), именно этот вариант и испробывал автор топика и мои комментарии были именно касательно этого мода, тут всё понятно: никакой высокой нагрузки при таком моде быть не может ни на какой платформе
T>кроме того, есть вариант, где рендеровка происходит на клиенте — это ближе к тому, что WebAssembly приложение, но это другая песня: там пока проблемы со стартом, так как в первый раз нужно грузить .NET runtime, что может быть слишком медленно и поэтому неприемлимо для любых, даже корпоративных пользователей
Да, я имел ввиду именно клиентский вариант, а не тот, который описал автор топика.
Но серверный вариант также запускает на клиенте WebAssembly. Только в случае северного варианта единственное что делает это приложение это открытие WebSocket и получение от сервера UI. Поэтому также потребуется загрузить .NET runtime.
Не соглашусь, что это неприемлемо для корпоративных пользователей. Если загрузка WebAssembly приложения и .NET runtime происходит 1 раз, когда сотрудник начинает работать с приложением (при приёме на работу), то ничего плохого не вижу. По идее системный администратор должен выдать железо с уже настроенным ПО. Плохо это как раз для не корпоративных пользователей, например для интернет магазина. Человеку что бы посмотреть товары придётся подождать. Может не хватить терпения и он перейдёт в магазин который покажет товары быстрее. Хотя если .NET runtime уже загружен время ожидания минимально, так как, насколько я знаю, в WebAssembly планируется загрузка по частям (по требованию). Загрузили начальный экран, показали пользователю. Дальше в фоне грузим остальную часть приложения.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Не соглашусь, что это неприемлемо для корпоративных пользователей. Если загрузка WebAssembly приложения и .NET runtime происходит 1 раз, когда сотрудник начинает работать с приложением (при приёме на работу), то ничего плохого не вижу. По идее системный администратор должен выдать железо с уже настроенным ПО. Плохо это как раз для не корпоративных пользователей, например для интернет магазина. Человеку что бы посмотреть товары придётся подождать. Может не хватить терпения и он перейдёт в магазин который покажет товары быстрее. Хотя если .NET runtime уже загружен время ожидания минимально, так как, насколько я знаю, в WebAssembly планируется загрузка по частям (по требованию). Загрузили начальный экран, показали пользователю. Дальше в фоне грузим остальную часть приложения.
Не будет ли размер загрузки приложения огромным, если он также включает среду выполнения .NET?
Не обязательно. .NET среды выполнения бывают разных форм в размерах. В ранних прототипах Blazor использовалась компактная среда выполнения .NET (включая сборку, сборку мусора, многопоточность), которая компилировалась всего в 60 КБ WebAssembly. Blazor теперь работает на Mono, который в настоящее время значительно больше, но возможностей для оптимизации размера предостаточно, включая слияние и обрезку исполняемых файлов и двоичных файлов приложений. Другие потенциальные меры по уменьшению размера загрузки включают кэширование и использование CDN.
Когда клиентское приложение Blazor создается и запускается в браузере:
Файлы кода C# и файлы Razor компилируются в сборки .NET.
Сборки и среда выполнения .NET загружаются в браузер.
Blazor на стороне клиента осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor на стороне клиента использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
Размер опубликованного приложения, известный как размер полезных данных, является критически важным фактором производительности для удобства работы с приложением. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor на стороне клиента оптимизирует размер полезных данных, чтобы сократить время скачивания:
При публикации неиспользуемый код исключается из приложения компоновщиком промежуточного языка.
HTTP-ответы сжимаются;
среда выполнения и сборки .NET кэшируются в браузере.
и солнце б утром не вставало, когда бы не было меня
S>Когда клиентское приложение Blazor создается и запускается в браузере:
S>Файлы кода C# и файлы Razor компилируются в сборки .NET.
S>Сборки и среда выполнения .NET загружаются в браузер.
S>Blazor на стороне клиента осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor на стороне клиента использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
S>Размер опубликованного приложения, известный как размер полезных данных, является критически важным фактором производительности для удобства работы с приложением. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor на стороне клиента оптимизирует размер полезных данных, чтобы сократить время скачивания:
S>При публикации неиспользуемый код исключается из приложения компоновщиком промежуточного языка.
S>HTTP-ответы сжимаются;
S>среда выполнения и сборки .NET кэшируются в браузере.
ой, ли?
когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?
Здравствуйте, takTak, Вы писали:
T>когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?
Ну JavaScript тоже грузить надо. Суть то в том, что блазорщики пошли по пути интерпритации и сжатия кода, за счет отброса ненужного.
Именно ради этого и делали .Net Standard. Как для докеров так и .Net Native. Сама Моно небольшая 1.7 MB, в сжатом 697 KB https://github.com/mono/mono/issues/9857
The download size of Blazor apps today is still pretty big even after running the IL linker. Currently the default Blazor project weighs in at 1.8 MB compressed, with the core runtime files making up ~80% of the size. The mono.wasm file is the biggest file, but mscorlib.dll is a close second:
Largest files in a default Blazor app
File
Size (uncompressed)
Size (compressed)
mono.wasm
1.7 MB
697 KB
mscorlib.dll
1.5 MB
656 KB
System.Core.dll
337 KB
138 KB
You can find the code for a default Blazor project here: https://github.com/danroth27/DefaultBlazorProject
Учитывая остается, что нужно, то максимум 2 мега для большого приложения . Это крохи
и солнце б утром не вставало, когда бы не было меня
T>>когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?
S> Учитывая остается, что нужно, то максимум 2 мега для большого приложения . Это крохи
всё-равно, 2 мв или не 2 — если нужно ждать несколько секунд (пусть даже из-за какого-то антивира), то это — на гране фола,
кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки
Здравствуйте, takTak, Вы писали:
T>>>когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?
S>> Учитывая остается, что нужно, то максимум 2 мега для большого приложения . Это крохи
T>всё-равно, 2 мв или не 2 — если нужно ждать несколько секунд (пусть даже из-за какого-то антивира), то это — на гране фола, T>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки
При 10 мб в сек?. Зато потом все кэшируется и выполняется быстро.
Учитывая, что SPA выигрывают в дальнейшем, за счет уменьшения скачиваемого контента, то в общем получается нехилая экономия.
В любом случае нужно дождаться .Net Core 3 23 сентября и посмотреть уже на релизный вариант.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, igor-booch, Вы писали:
IB>Но серверный вариант также запускает на клиенте WebAssembly. Только в случае северного варианта единственное что делает это приложение это открытие WebSocket и получение от сервера UI. Поэтому также потребуется загрузить .NET runtime.
Нет. Сейчас специально перепроверил (может я ошибся) — грузится только javascript:
Здравствуйте, takTak, Вы писали:
T>кроме того, есть вариант, где рендеровка происходит на клиенте — это ближе к тому, что WebAssembly, но это другая песня: там пока проблемы со стартом, так как в первый раз нужно грузить .NET runtime, что может быть слишком медленно и поэтому неприемлимо для любых, даже корпоративных пользователей
Сейчас проверил на свежем приложении — 3-4 секунды. С одно стороны вроде не мало, с другой — я не видел корпоративного софта, который поражает воображение отзывчивостью. А именно от WASM могут быть весомые плюсы, когда, нужно проделать какие-то действия с (например) файлом на стороне клиента. То есть вся это можно и js реализовать, но так зачастую будет удобнее как для разработчика, так и для пользователя.
Здравствуйте, takTak, Вы писали:
T>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки
Прежде всего я выбрал серверный вариант из-за 1-tier архитектуры. И переключить её на n-tier (клиентский Blazor) легко не выйдет. Насчёт времени запуска уже ответил, насчёт размеров — всё зависит от того, что вы подключите в проект. В принципе да, каждая библиотека может увеличить код — будет ли это проблемой зависит исключительно от назначения приложения.
T>>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки
S>Прежде всего я выбрал серверный вариант из-за 1-tier архитектуры. И переключить её на n-tier (клиентский Blazor) легко не выйдет.
вот тут, пожалуйста, поподробнее: что значит: "легко не выйдет" переключить, по памяти это было как раз на какой-то рекламной презентации блейзора, вроде как должно быть очень легко сделать
Здравствуйте, takTak, Вы писали:
T>вот тут, пожалуйста, поподробнее: что значит: "легко не выйдет" переключить, по памяти это было как раз на какой-то рекламной презентации блейзора, вроде как должно быть очень легко сделать
Я не смотрел презентацию, но сами подумайте: в 1-tier я могу непосредственно из компонента обратиться к базе, например, или к rabbitmq — как я это сделаю из n-tier? Сами шаблоны этих приложений разные: 1-tier состоит из одного проекта, который объединяет клиент и сервер, n-tier из трёх: клиент, сервер и общие классы.
T>>вот тут, пожалуйста, поподробнее: что значит: "легко не выйдет" переключить, по памяти это было как раз на какой-то рекламной презентации блейзора, вроде как должно быть очень легко сделать
S>Я не смотрел презентацию, но сами подумайте: в 1-tier я могу непосредственно из компонента обратиться к базе, например, или к rabbitmq — как я это сделаю из n-tier? Сами шаблоны этих приложений разные: 1-tier состоит из одного проекта, который объединяет клиент и сервер, n-tier из трёх: клиент, сервер и общие классы.
я уже не помню деталей, просто в чём особенная сложность разделения слоя доступа данных вместо одного проекта на 2-3: накладные расходы связаны разве что с сериализацией?!
а, ну так тогда получается, что это в серверном моде старт длится 3-4 секунды? тогда в клиентском всё будет намного дольше....
Здравствуйте, takTak, Вы писали:
T>я уже не помню деталей, просто в чём особенная сложность разделения слоя доступа данных вместо одного проекта на 2-3: накладные расходы связаны разве что с сериализацией?!
См. первое сообщение темы.
T>а, ну так тогда получается, что это в серверном моде старт длится 3-4 секунды? тогда в клиентском всё будет намного дольше....
Нет, 3-4 секунды — это про клиентский вариант, я сейчас создал новый проект по шаблону. Серверный вариант (после инициализации самого приложения), отдаёт первую пререндеренную страницу примерно за 300-700 мс под отладчиком, а после этого только обновляет её. В локальной сети каких-либо задержек не заметно вообще.
ЗЫ. Насчёт отладки: в серверном варианте всё отлично, в клиентском в предыдущих превью было криво, в новом не проверял.
T>>я уже не помню деталей, просто в чём особенная сложность разделения слоя доступа данных вместо одного проекта на 2-3: накладные расходы связаны разве что с сериализацией?!
S>См. первое сообщение темы.
T>>а, ну так тогда получается, что это в серверном моде старт длится 3-4 секунды? тогда в клиентском всё будет намного дольше....
S>Нет, 3-4 секунды — это про клиентский вариант, я сейчас создал новый проект по шаблону. Серверный вариант (после инициализации самого приложения), отдаёт первую пререндеренную страницу примерно за 300-700 мс под отладчиком, а после этого только обновляет её. В локальной сети каких-либо задержек не заметно вообще.
S>ЗЫ. Насчёт отладки: в серверном варианте всё отлично, в клиентском в предыдущих превью было криво, в новом не проверял.
ок, но согласись: между 4 сек и 0,5 секундами разница есть...
мне диковато представить, чтобы пользователь в 2019 году сидел и ждал 4 секунды, пока появится приложение, написанное на одном из самых модных фреймворков
Здравствуйте, takTak, Вы писали:
T>ок, но согласись: между 4 сек и 0,5 секундами разница есть...
T>мне диковато представить, чтобы пользователь в 2019 году сидел и ждал 4 секунды, пока появится приложение, написанное на одном из самых модных фреймворков
Смотрите: сейчас ради интереса посмотрел на установленный у нас LanSweeper — открытие титульной страницы 20 сек (до полной загрузки), открытие подробностей о компьютере — 3-5 сек. У Configuration Manager применение фильтров, получение списков, построение отчётов может идти достаточно долго. Про 1С-ников просто молчу — там о каком-либо реалтайме речь уже даже близко не идёт.
Само собой для какого-нибудь лендинга или простого сайта 4 секунды это много (хотя скорее всего ещё оптимизируют), но для рабочих приложений это вполне приемлемо. Плюс могут добавить net nativе, а это уже очень высокая скорость запуска.
