Pull to refresh
13
0
Алексей Фомкин @yelbota

Программист, руководитель

Send message

Да, обсуждали сходство в комментах к моему посту. Непонятен только вес рантайма для сервер-сайд режима. Если он весит мегабайты как Vaadin, то это не имеет особого смысла. Королев специально сделан так чтобы весить минимально.

Если речь о тестах проверяющих сам Королев, то нет, не до конца. Работает через раз. Выглядит так будто сервер проглатывает события. Я бы грешил на сам Королев, но есть тесты производительности/корректности, которые работают по реальному "накликаному" логу событий и там 100% детерминизм даже под дикой нагрузкой (т.е. события таки не проглатываются). Возможно проблема в Sauce Connect Proxy. Надо садиться и дебажить, а времени особо нет.

То есть игра с анимациями и вот этим всем Вас не убеждает?

Действительно. Судя по этой статье разработчики Blazor идут по очень похожему пути что я с королевым.


However, the design of the Blazor framework is smart and flexible enough to run the application separate from rendering process. For example, we can run Blazor in a web worker thread separately from UI thread.

Я делал такое на Scala.js в 2014 https://medium.com/@yelbota/-18195d44f574 Потом мне в голову пришла идея, что то что крутится в веб-воркере может крутиться на сервере. Я совместил это с идеями React/Redux так и получился Korolev.

Судя по описанию Blazor больше похоже на Vaadin.


Running .NET code inside web browsers is made possible by WebAssembly (abbreviated wasm). WebAssembly is an open web standard and supported in web browsers without plugins. WebAssembly is a compact bytecode format optimized for fast download and maximum execution speed.

Вес клиентской части все же достаточно большой, не смотря на то что компоненты управляются с сервера. Королев не грузит ничего дополнительного, если сам программист этого не захотел. 6 Кбайт несжатого JS достаточно для работы.

А без интернета не работает вовсе!

Для интеграции JS предлагается использовать веб-компоненты. Типичный пример — карты.

Вся нагрузка с миллиона раскалённых айпадов в полном объёме переедет на сервер, который от такого расправится и стечёт в подвал.

Но пользователь этого не заметит.

Из этой статьи не очевидно как реализовать подобное Королеву. Судя по документации ReactDOMServer это и не предполагается. Чтобы работало как в Королеве нужен метод который будет рендерить в список событий для отправки по веб-сокету. При чем он должен выдавать только изменения. Опять же на стороне клиента должен быть механизм, который такие списки будет обрабатывать.

1) Круто! Можно ссылку на пример?

Во-первых, на сколько я понимаю, React не позволяет обрабатывать события на сервере, а предлагает только рендер начального состояния. Во-вторых React 16 вышел на год позже Королева. Хотя в любом случае изобретение не мое. Ниже в комментариях есть ссылка на проект с подобной философией для языка Erlang.

Подобная идея давно имеет реализация в erlang n2o (можно сделать интерактивное приложение без знаний js)

Да, n2o один из источников вдохновения. При всей нелюбви к Максу Сохацкому лично, надо отдать ему должное: в своей работе он воплощает то каким софт должен быть на мой взгляд. В Королеве несколько другой подход к работке.


Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».

Можно. В Королеве для этого предлагается использовать веб-компоненты.

королев, Королев, Королёв, Korolev, korolev. Как Вам угодно :)

В такой постановке это ни о чём не говорит. Может у вас на каждый клик там два байта обновлений;

На каждый клик сравнение двух версий виртуального DOM. 1 млн. CCU это чудовищно много. Такие показатели бывают только у супер-разрекламированных онлайн-игр на запуске. Представим что нормальный сервак держит 10000 CCU. Если уж у вашего сервиса такая популярность, то купить 100 серверов не большая проблема.

Ну и к чему тогда у вас там сарказм про глупых фронтэндеров

Это не сарказм, а реальное положение дел. В начале пилит Вася, потом к нему присоединяются Петя с Колей, потом Вася увольняется и пошло-поехало. К сожалению разработка выстроена не всегда грамотно. Особенно в стартапах.


У вас тоже — оп, и стало два.

Использовать Королев и Реакт совместно довольно проблемно.


Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны.

Кто-то должен платить. По вашему будет лучше, если заплатить пользователь? Почему мы продолжаем делать веб на PHP, Ruby, Python, а не перейдем, на пример на Rust чтобы платить еще меньше?


Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны. «Тупой» тонкий слой бэка, собирающий что-то там из базы или из нижележащих сервисов, и бэк, который рисует всем их DOM — это совсем разные вычислительные нагрузки.

Надо замерять. Невозможно сравнить Королев и условный веб-сервер собирающий JSON. Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.

Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.

О том и разговор. Можно ходить к БД на прямую, к очереди напрямую, к микросервисам напрямую и так далее.


За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.

Кто знает? Может быть клиент готов платить за софт который не тормозит и не выжирает всю память, а менеджер просто не в курсе что так можно было?

На мой взгляд с масштабируемостью серверных мощностей как раз таки проблем нет. У есть есть виртуальные сервера в облаках и мы можем динамически добавлять серверные мощности в случае наплыва пользователь. Достаточно, чтобы сервис умел масштабироваться горизонтально. С другой стороны повлиять на конечное устройство мы не можем. Оно может быть медленным, устаревшим, завирусованым и так далее. Чем слабее мы его нагрузим, тем лучше.

Под «рендерить» подразумевается отображение бизнес-данных в браузерный DOM. Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
MVC умер, да здравствует MVC!
Сейчас эникещиков будет корежить.
Никто ни вчем не виноват. Поясню на примере. Есть программист который пишет программы под специальные промышленные восьмибитные процессоры, в которых самый минимальный набор инструкций. Созданы они были 20 лет назад и до сих пор всех устраивают. Этот программист пишет замечательные программы на ассемблере для этого процессора, которые не тормозят, не текут, работают годами без сбоев. Более того, когда этим летом, на практику к нему пришли стажеры из университета, они без труда поняли код прошивок, которые он написал. Что тут можно сказать? Это замечательный программист, великолепно знающий свою область, обладающий системным мышлением, думающий о коллегах и о цели своей работы. Однако ему будет не о чем говорить на конференции. Зачем же ему ехать?

Я специально утрирую, потому что разработка для микроконтроллеров не лишена романтики. В глубине души, любому разработчику хочется программировать огромные станки и космические корабли, и все равно на чем. Но в действительности в этой теме нет ничего интересного для современных разработчиков. Ассемблер, он и в Африке ассемблер.

Или другой пример. Вот допустим дикий негр из племени мумба-юмба. Может быть он отличный человек, и даже прогрессивный по меркам своего племени. На пример считает, что нет особых отличий между поеданием сердца врага и его задницы: сил одинаково прибавляет. В племени его за это считают чудаком, а некоторые заявляют, мол больно умный. Будет ли интересно с ним пообщаться?

Information

Rating
Does not participate
Location
Королев, Москва и Московская обл., Россия
Date of birth
Registered
Activity