Comments 48
Первый связан с тем что серверный рендеринг воспринимается как что-то медленное, не интерактивное.
Вы сейчас с чьими фантазиями в чьей голове говорите?
Серверный рендеринг нигде и никем (вменяемым) не воспринимался как «медленное». Это всегда самое что ни на есть быстрое, только процессорные мощности должны быть на 100% ваши. У вас миллион пользователей в секунду и каждому надо посчитать его DOM? Вот и будьте добры считать, без перегрузок и отказов обслуживания.
То же самое с интерактивностью. Если вы пишете нам из 2019 года, то пора бы уж понимать, что в этом году уже много лет можно сделать серверный рендеринг интерактивным без особых проблем. Вопрос — опять же, в процессорных мощностях, которые будут целиком на вашей стороне и должны обслуживать всех клиентов.
Критические проблемы серверного рендеринга не в том, что вы написали, а в масштабируемости (помним про процессорные мощности целиком на вашей стороне) и в неустранимом оверхеде на рендеринг — сервер не владеет информацией о том, что и как нужно рендерить (поскольку не является конечным устройством), и в хоть сколько-нибудь сложных случаях должен сначала получать информацию о конечном устройстве (вплоть до размера окна браузера, если вы, скажем, графику масштабируемую рисуете), а потом генерировать ответ — это лишний блокирующий рендер запрос на сервер, которого принципиально нет в «обычном» фронтэнде и который будет у вас в любых достаточно сложных случаях.
Под «рендерить» подразумевается отображение бизнес-данных в браузерный DOM. Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
Ну и к чему тогда у вас там сарказм про глупых фронтэндеров, от безвыходности использующих два фреймворка? У вас тоже — оп, и стало два.
На мой взгляд с масштабируемостью серверных мощностей как раз таки проблем нет.
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны. «Тупой» тонкий слой бэка, собирающий что-то там из базы или из нижележащих сервисов, и бэк, который рисует всем их DOM — это совсем разные вычислительные нагрузки.
Ну и к чему тогда у вас там сарказм про глупых фронтэндеров
Это не сарказм, а реальное положение дел. В начале пилит Вася, потом к нему присоединяются Петя с Колей, потом Вася увольняется и пошло-поехало. К сожалению разработка выстроена не всегда грамотно. Особенно в стартапах.
У вас тоже — оп, и стало два.
Использовать Королев и Реакт совместно довольно проблемно.
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны.
Кто-то должен платить. По вашему будет лучше, если заплатить пользователь? Почему мы продолжаем делать веб на PHP, Ruby, Python, а не перейдем, на пример на Rust чтобы платить еще меньше?
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны. «Тупой» тонкий слой бэка, собирающий что-то там из базы или из нижележащих сервисов, и бэк, который рисует всем их DOM — это совсем разные вычислительные нагрузки.
Надо замерять. Невозможно сравнить Королев и условный веб-сервер собирающий JSON. Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
Это не сарказм, а реальное положение дел.
Ну а у вас реальное положение дел — это «у нас серверный рендеринг! ой, а картинку как-нибудь сами нарисуйте». То есть, настолько же всё плохо.
Использовать Королев и Реакт совместно довольно проблемно.
Дело не в реакте, а в том, что мне надо какое-то второе решение, чтоб картинки на клиенте (подогнанные под клиента) рисовать.
По вашему будет лучше, если заплатить пользователь?
Конечно. Подавляющее большинство пользователей, открывая вашу страничку, делают это на очень неплохих процессорных мощностях. Которые спокойно отрисуют этот ваш DOM и вообще много чего сделают, особенно если делать это вменяемыми способами.
Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
В такой постановке это ни о чём не говорит. Может у вас на каждый клик там два байта обновлений; в такой ситуации «дохлый макбук 2013 года» и с миллионами пользователей сможет справиться.
ЗЫ: Это кстати любопытно, что вы сами гоняете «дохлый макбук 2013 года» как сервер, но при этом считаете, что у пользователей с мощностями всё настолько плохо, что их надо разгружать. В то время как пользователи как раз с подобных систем и будут ваши странички открывать.
особенно если делать это вменяемыми способами
Вот с этим, к сожалению, на фронте основные проблемы.
P.S. Т.е. понятно, что не все проекты такие. Но таковых подавляющее большинство.
Вот с этим, к сожалению, на фронте основные проблемы.
Это не проблемы технологий фронтэнда.
Но проблемы людей, делающих этот самый фронтэнд, по другому просто не решить. Только созданием технологий которые уменьшают появление проблем создаваемых людьми.
В противном случае мы дальше С и С++ просто не ушли. Все бы делали без ошибок на этих языках. А может и дальше ассемблера, кто знает)
В такой постановке это ни о чём не говорит. Может у вас на каждый клик там два байта обновлений;
На каждый клик сравнение двух версий виртуального DOM. 1 млн. CCU это чудовищно много. Такие показатели бывают только у супер-разрекламированных онлайн-игр на запуске. Представим что нормальный сервак держит 10000 CCU. Если уж у вашего сервиса такая популярность, то купить 100 серверов не большая проблема.
Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
Сортировку списка дрегендропом реализуйте, пожалуйста.
habr.com/post/339148
Во-первых, на сколько я понимаю, React не позволяет обрабатывать события на сервере, а предлагает только рендер начального состояния. Во-вторых React 16 вышел на год позже Королева. Хотя в любом случае изобретение не мое. Ниже в комментариях есть ссылка на проект с подобной философией для языка Erlang.
2) SSR есть в react с древних версий, в статье по ссылке описаны новые возможности просто.
1) Круто! Можно ссылку на пример?
Ну и чтобы дальше не развивать — решений может быть много, в т/ч/ прокидывать состояние через react router
Из этой статьи не очевидно как реализовать подобное Королеву. Судя по документации ReactDOMServer это и не предполагается. Чтобы работало как в Королеве нужен метод который будет рендерить в список событий для отправки по веб-сокету. При чем он должен выдавать только изменения. Опять же на стороне клиента должен быть механизм, который такие списки будет обрабатывать.
За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.
Современная веб разработка, это гибкость к изменениям. Сделать что-то быстро и качественно. (Ну или хотя бы найти компромис).
Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.
Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.
О том и разговор. Можно ходить к БД на прямую, к очереди напрямую, к микросервисам напрямую и так далее.
За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.
Кто знает? Может быть клиент готов платить за софт который не тормозит и не выжирает всю память, а менеджер просто не в курсе что так можно было?
Может быть клиент готов платить за софт который не тормозит и не выжирает всю память
Для такого софта не нужен именно серверный рендеринг. Даже «медленное устаревшее завирусованное» устройство уж как-нибудь у себя интерактивную HTML-страничку покажет без особых проблем. Если не нагружать его бессмысленной работой и не заставлять скачивать мегабайты JS. Кстати, у серверной интерактивности и мегабайт JS слабое место одно и то же — при плохом качестве связи первое не работает, а второе — не скачивается.
При плохом качестве интернета проблемы будут разные. Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально. Так что ваше «первое не работает» далеко от истины. Только в каких-то совсем крайних случаях, когда все другие способы давно перестали работать…
Если, если, если, если… У вас очень много условий
Да что вы говорите. Мои «много условий» — это «нормально делай, нормально будет». Говнокодом я вам и серверный рендеринг зарою так, что никаких серверов в облаках не хватит.
Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально.
При плохом интернете вас ждут разрывы соединений (это то самое, что не даёт вам скачать 1Мб клиента, если что) — и это означает, что ваши запросы местами не будут уходить на сервер, местами будут тормозить (и разницы между «оборвалось» и «тормозит» вы, как пользователь, не увидите), и местами ответы не будут приходить — потому что не пришли или пришли не полностью.
Работать с «серверной интерактивностью» в таких случаях сложно даже в крайне простых случаях типа ssh.
Я сейчас проверил, приложение из статьи при перебоях с интернетом просто зависает.
Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».
Подобная идея давно имеет реализация в erlang n2o (можно сделать интерактивное приложение без знаний js)
Да, n2o один из источников вдохновения. При всей нелюбви к Максу Сохацкому лично, надо отдать ему должное: в своей работе он воплощает то каким софт должен быть на мой взгляд. В Королеве несколько другой подход к работке.
Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».
Можно. В Королеве для этого предлагается использовать веб-компоненты.
Давно ждал господина Фомкина на Хабре, дождались !
Вся нагрузка с миллиона раскалённых айпадов в полном объёме переедет на сервер, который от такого расправится и стечёт в подвал.
Проблема с жирным тормозным хрупким вебом не техническая, ИМХО.
Не думали про композитный подход? когда korolev component может содержать css/js? Когда первоначальный рендер происходит на сервере, а динамическое обновление html возможно как по инициативе сервере, так и по инициативе клиента — либо запросом ререндера с сервера, либо прямой манипуляцией DOM.
Для интеграции JS предлагается использовать веб-компоненты. Типичный пример — карты.
Но это ведь вроде как пройденный этап? Если я не ошибаюсь у microsoft был похожий подход, там даже вместо js на c#(или vb) писались скрипты, состояние страницы хранилось фактически на сервере. Ну конечно тогда не было websocket, но не суть. Ведь очень дорого с точки зрения памяти хранить состояние страницы клиента на сервере, если её не хранить, то значит гонять большие массивы данных туда сюда этого состояния. Очевидно что положить такой сервис не составит труда. Сколько памяти приходится на один конекшн(для сервера рендеринга) при таком подходе? Сейчас вам надо поддерживать одно api для всех платформ web ios android. И все быстро работает потому что посылаются только компактно уложенные в json данные. На каждый клик при котором производится взаимодействие лезть на сервер это жесть при нестабильном соединении. При падении сервера, который держал состояние клиента как восстановить состояние?
Вобщем-то подобные тенденции здорово летают в воздухе — и скорее всего займут свою нишу.
Вот недавная статья о подобной технологии на Elixir: https://habr.com/en/post/452724/
Правда там все запихано прямо в наиболее популярный и поддерживаемый фреймворк.
Но всетки трудно не согласится с тем, что анимации будут тормозить, а сервера будут стекать под жесткой нагрузкой. В связи с этим видится разумным разделение логики на данные и отображение, и все-таки передачу туда-сюда только состояния, связанное с данными. Возможно — web components будет действительно лучшим решением для такого разделения.
В .NET Core 3.0 будет из коробки.
Судя по описанию 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 достаточно для работы.
TL;DR: Там два варианта работы на выбор:
1. Client-side — Mono runtime компилируется в wasm и исполняет C# код в браузере вместо JS. Не особо ценно, кроме как возможностью писать ПЕРЕДНИЙ КОНЕЦ, не шкварясь об JS.
2. И, собственно, server-side — очень тонкая JS-прослойка на клиенте, которая вызывает RPC на сервере через WebSocket, точно так же, как ваш Королев.
Действительно. Судя по этой статье разработчики 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.
А как там функциональные тесты, починились?
Если речь о тестах проверяющих сам Королев, то нет, не до конца. Работает через раз. Выглядит так будто сервер проглатывает события. Я бы грешил на сам Королев, но есть тесты производительности/корректности, которые работают по реальному "накликаному" логу событий и там 100% детерминизм даже под дикой нагрузкой (т.е. события таки не проглатываются). Возможно проблема в Sauce Connect Proxy. Надо садиться и дебажить, а времени особо нет.
Королев. Лекарство для веба