Blazor: n-tier vs 1-tier
От: Somescout  
Дата: 08.09.19 16:20
Оценка: 5 (4)
Тут уже несколько раз упоминали Blazor, но всё время в контексте WebAssebly (Client-side blazor). А я вот попробовал сделать небольшой проект в серверном варианте, и это... охрененно. Как будто снова пишешь простое приложение, без клиент-серверных api на каждый чих, (почти) без Java-/Typescript, без разделения на слои. Говнокодишь, но говнокодишь стильно.

Для тех кто не в курсе: Серверный вариант Blazor загружает на клиенте небольшую библиотеку и открвывает WebSocket к приложению на сервере, которое обрабатывает все действия пользователя (или события сторонних компонентов), обновляет у себя виртуальный DOM и при необходимости отправляет набор изменений, которые нужно внести в веб-страницу. Фактически получается одно приложение со множеством клиентских интерфейсов — веб-терминал.

Из того что понравилось:

Из минусов:

PS. Не то что бы совсем холиварная тема, но речь скорее не о технологии (Blazor), а идеологии (n-tier), так что пусть будет тут.
ARI ARI ARI... Arrivederci!
Re: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 08.09.19 16:27
Оценка:
так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...

приятно знать, что кто-то уже тренируется на кошечках, тоже надеюсь как-нибудь приступить
Re: Blazor: n-tier vs 1-tier
От: Mamut Швеция http://dmitriid.com
Дата: 09.09.19 09:32
Оценка:
S>Для тех кто не в курсе: Серверный вариант Blazor загружает на клиенте небольшую библиотеку и открвывает WebSocket к приложению на сервере, которое обрабатывает все действия пользователя (или события сторонних компонентов), обновляет у себя виртуальный DOM и при необходимости отправляет набор изменений, которые нужно внести в веб-страницу. Фактически получается одно приложение со множеством клиентских интерфейсов — веб-терминал.

Аналогично, скажем Phoenix LiveView для Elixir'а. У такого подхода очень ограниченная сфера применения. Я тут тред запилил: https://twitter.com/dmitriid/status/1153586545426862080


dmitriid.comGitHubLinkedIn
Re[2]: Blazor: n-tier vs 1-tier
От: Somescout  
Дата: 09.09.19 09:44
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Аналогично, скажем Phoenix LiveView для Elixir'а. У такого подхода очень ограниченная сфера применения. Я тут тред запилил:


С одной стороны это так: да, и зарезервированная для одного View память, и возможные утечки — всё это может больно ударить.
Но:
1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом
2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.
ARI ARI ARI... Arrivederci!
Re[2]: Blazor: n-tier vs 1-tier
От: igor-booch Россия  
Дата: 09.09.19 09:50
Оценка:
T>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...
Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности.
Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 09:53
Оценка:
S>1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом
S>2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.

любое stateless-приложение (тот же asp.net web api) без проблем скалируeтся на самом дешёвом железе
Отредактировано 09.09.2019 9:58 takTak . Предыдущая версия .
Re[3]: Blazor: n-tier vs 1-tier
От: Mamut Швеция http://dmitriid.com
Дата: 09.09.19 09:54
Оценка:
S>1) 100k пользователей это уже весьма приличное количество, чтобы озаботиться хорошим железом

100k пользователей — это ни о чем в классических приложениях.

S>2) На таких объёмах любое statefull-приложение (тот же asp.net/mvc/core) может получить похожие проблемы.


Не получит. Потому что там будет не UI стейт, а пользовательский стейт и/или данные. UI-стейт очень редко хранится на сервере. В случае, когда всё на сервере, включая UI, становится печально.

Но для внутренних продуктов это может быть очень удобной вещью.


dmitriid.comGitHubLinkedIn
Re[3]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 09:56
Оценка:
T>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...
IB>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности.
IB>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.

что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели
Re[4]: Blazor: n-tier vs 1-tier
От: igor-booch Россия  
Дата: 09.09.19 13:13
Оценка:
T>>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...
IB>>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности.
IB>>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.
T>что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели

Ты заявил, что Blazor не подходит для высоконагруженных приложений.
Под высоконагруженными приложениями я понимаю большое количество одновременно работающих пользователей. Если так то я вообще не понимаю при чём здесь Blazor.
Я предположил, что под высоконагруженными приложениями ты принимаешь приложения с нагруженным (богатым) пользовательским интерфейсом. Здесь, уже применимо, то что я написал про производительность, как быстрый отклик приложения на действия пользователя.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 13:26
Оценка:
T>>>>так авторы вроде как и говорили, что для простой интранет-шняги- самое то, но никак не для высоконагруженных приложений...
IB>>>Какие авторы такое говорили? Я читал что одна из целей создания WebAssembly — повышение производительности.
IB>>>Может быть на данный момент, пока WA на стадии MVP, есть проблемы с производительностью, но по задумке их в конечном итоге не должно быть.
T>>что ты понимаешь под "производительностью"? есть производительность разработчика, который за два часа или два дня может наваять готовое приложение, блэйзор приближает к этой цели

IB>Ты заявил, что Blazor не подходит для высоконагруженных приложений.

IB>Под высоконагруженными приложениями я понимаю большое количество одновременно работающих пользователей. Если так то я вообще не понимаю при чём здесь Blazor.
IB>Я предположил, что под высоконагруженными приложениями ты принимаешь приложения с нагруженным (богатым) пользовательским интерфейсом. Здесь, уже применимо, то что я написал про производительность, как быстрый отклик приложения на действия пользователя.

тогда ты меня неправильно понял, майкрософтовский блэйзор предлагает опцию, где рендеровка происходит на сервере (server-side), именно этот вариант и испробывал автор топика и мои комментарии были именно касательно этого мода, тут всё понятно: никакой высокой нагрузки при таком моде быть не может ни на какой платформе

кроме того, есть вариант, где рендеровка происходит на клиенте — это ближе к тому, что WebAssembly, но это другая песня: там пока проблемы со стартом, так как в первый раз нужно грузить .NET runtime, что может быть слишком медленно и поэтому неприемлимо для любых, даже корпоративных пользователей
Re[6]: Blazor: n-tier vs 1-tier
От: igor-booch Россия  
Дата: 09.09.19 13:46
Оценка:
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
Отредактировано 09.09.2019 14:56 igor-booch . Предыдущая версия .
Re[7]: Blazor: n-tier vs 1-tier
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.09.19 14:39
Оценка: 2 (1)
Здравствуйте, igor-booch, Вы писали:

IB>Не соглашусь, что это неприемлемо для корпоративных пользователей. Если загрузка WebAssembly приложения и .NET runtime происходит 1 раз, когда сотрудник начинает работать с приложением (при приёме на работу), то ничего плохого не вижу. По идее системный администратор должен выдать железо с уже настроенным ПО. Плохо это как раз для не корпоративных пользователей, например для интернет магазина. Человеку что бы посмотреть товары придётся подождать. Может не хватить терпения и он перейдёт в магазин который покажет товары быстрее. Хотя если .NET runtime уже загружен время ожидания минимально, так как, насколько я знаю, в WebAssembly планируется загрузка по частям (по требованию). Загрузили начальный экран, показали пользователю. Дальше в фоне грузим остальную часть приложения.


Там нет .NET runtime, Там Mono который интерпретирует код. А моно небольшой 60KB
https://github.com/aspnet/Blazor/wiki/FAQ

Не будет ли размер загрузки приложения огромным, если он также включает среду выполнения .NET?

Не обязательно. .NET среды выполнения бывают разных форм в размерах. В ранних прототипах Blazor использовалась компактная среда выполнения .NET (включая сборку, сборку мусора, многопоточность), которая компилировалась всего в 60 КБ WebAssembly. Blazor теперь работает на Mono, который в настоящее время значительно больше, но возможностей для оптимизации размера предостаточно, включая слияние и обрезку исполняемых файлов и двоичных файлов приложений. Другие потенциальные меры по уменьшению размера загрузки включают кэширование и использование CDN.


Здесь пишут так
https://docs.microsoft.com/ru-ru/aspnet/core/blazor/?view=aspnetcore-3.0

Когда клиентское приложение Blazor создается и запускается в браузере:
Файлы кода C# и файлы Razor компилируются в сборки .NET.
Сборки и среда выполнения .NET загружаются в браузер.
Blazor на стороне клиента осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor на стороне клиента использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
Размер опубликованного приложения, известный как размер полезных данных, является критически важным фактором производительности для удобства работы с приложением. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor на стороне клиента оптимизирует размер полезных данных, чтобы сократить время скачивания:
При публикации неиспользуемый код исключается из приложения компоновщиком промежуточного языка.
HTTP-ответы сжимаются;
среда выполнения и сборки .NET кэшируются в браузере.

и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.09.2019 14:44 Serginio1 . Предыдущая версия .
Re[8]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 15:05
Оценка:
S> Там нет .NET runtime, Там Mono который интерпретирует код. А моно небольшой 60KB
S>https://github.com/aspnet/Blazor/wiki/FAQ


S>

S>Когда клиентское приложение Blazor создается и запускается в браузере:
S>Файлы кода C# и файлы Razor компилируются в сборки .NET.
S>Сборки и среда выполнения .NET загружаются в браузер.
S>Blazor на стороне клиента осуществляет начальную загрузку среды выполнения .NET и настраивает ее для загрузки сборок для приложения. Среда выполнения Blazor на стороне клиента использует взаимодействие с JavaScript для обработки операций с моделью DOM и вызовов API браузера.
S>Размер опубликованного приложения, известный как размер полезных данных, является критически важным фактором производительности для удобства работы с приложением. Крупное приложение скачивается в браузере довольно долго, что ухудшает взаимодействие с пользователем. Blazor на стороне клиента оптимизирует размер полезных данных, чтобы сократить время скачивания:
S>При публикации неиспользуемый код исключается из приложения компоновщиком промежуточного языка.
S>HTTP-ответы сжимаются;
S>среда выполнения и сборки .NET кэшируются в браузере.


ой, ли?

когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?
Re[9]: Blazor: n-tier vs 1-tier
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.09.19 15:17
Оценка:
Здравствуйте, 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 мега для большого приложения . Это крохи
и солнце б утром не вставало, когда бы не было меня
Re[10]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 15:28
Оценка:
T>>когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?

S> Учитывая остается, что нужно, то максимум 2 мега для большого приложения . Это крохи


всё-равно, 2 мв или не 2 — если нужно ждать несколько секунд (пусть даже из-за какого-то антивира), то это — на гране фола,
кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки
Re[11]: Blazor: n-tier vs 1-tier
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.09.19 15:51
Оценка:
Здравствуйте, takTak, Вы писали:

T>>>когда эту штуковину показывают, несколько секунд первая загрузка длится, и это- на уровне "хелло, мир"а, что будет с приложением побольше?


S>> Учитывая остается, что нужно, то максимум 2 мега для большого приложения . Это крохи


T>всё-равно, 2 мв или не 2 — если нужно ждать несколько секунд (пусть даже из-за какого-то антивира), то это — на гране фола,

T>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки

При 10 мб в сек?. Зато потом все кэшируется и выполняется быстро.
Учитывая, что SPA выигрывают в дальнейшем, за счет уменьшения скачиваемого контента, то в общем получается нехилая экономия.

В любом случае нужно дождаться .Net Core 3 23 сентября и посмотреть уже на релизный вариант.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.09.2019 16:16 Serginio1 . Предыдущая версия .
Re[7]: Blazor: n-tier vs 1-tier
От: Somescout  
Дата: 09.09.19 16:26
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Но серверный вариант также запускает на клиенте WebAssembly. Только в случае северного варианта единственное что делает это приложение это открытие WebSocket и получение от сервера UI. Поэтому также потребуется загрузить .NET runtime.


Нет. Сейчас специально перепроверил (может я ошибся) — грузится только javascript:
http://files.rsdn.org/103613/BlazorServerSide.png
ARI ARI ARI... Arrivederci!
Re[6]: Blazor: n-tier vs 1-tier
От: Somescout  
Дата: 09.09.19 16:29
Оценка:
Здравствуйте, takTak, Вы писали:

T>кроме того, есть вариант, где рендеровка происходит на клиенте — это ближе к тому, что WebAssembly, но это другая песня: там пока проблемы со стартом, так как в первый раз нужно грузить .NET runtime, что может быть слишком медленно и поэтому неприемлимо для любых, даже корпоративных пользователей


Сейчас проверил на свежем приложении — 3-4 секунды. С одно стороны вроде не мало, с другой — я не видел корпоративного софта, который поражает воображение отзывчивостью. А именно от WASM могут быть весомые плюсы, когда, нужно проделать какие-то действия с (например) файлом на стороне клиента. То есть вся это можно и js реализовать, но так зачастую будет удобнее как для разработчика, так и для пользователя.
ARI ARI ARI... Arrivederci!
Re[11]: Blazor: n-tier vs 1-tier
От: Somescout  
Дата: 09.09.19 16:34
Оценка:
Здравствуйте, takTak, Вы писали:

T>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки


Прежде всего я выбрал серверный вариант из-за 1-tier архитектуры. И переключить её на n-tier (клиентский Blazor) легко не выйдет. Насчёт времени запуска уже ответил, насчёт размеров — всё зависит от того, что вы подключите в проект. В принципе да, каждая библиотека может увеличить код — будет ли это проблемой зависит исключительно от назначения приложения.
ARI ARI ARI... Arrivederci!
Re[12]: Blazor: n-tier vs 1-tier
От: takTak  
Дата: 09.09.19 16:40
Оценка:
T>>кстати, автор топика может легко переключить на клиентский мод, пусть он попробует и скажет, какое отличие, он выбрал ведь именно серверный вариант, и я подозреваю, что только из-за времени первой загрузки

S>Прежде всего я выбрал серверный вариант из-за 1-tier архитектуры. И переключить её на n-tier (клиентский Blazor) легко не выйдет.



вот тут, пожалуйста, поподробнее: что значит: "легко не выйдет" переключить, по памяти это было как раз на какой-то рекламной презентации блейзора, вроде как должно быть очень легко сделать
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.