Около года назад вышла статья-манифест Никиты Прокопова о разочаровании в программном обеспечении. Судя по положительным откликам, разработчикам небезразлично качество производимых продуктов. Может быть пора начать действовать?
В этой заметке я хочу рассказать о своей разработке, которая, по моему мнению, может вылечить основные проблемы производительности современного веба и сделать пользователя немного счастливее. Проблемы такие: большой вес JS-кода, высокое время до начала работы со страницей (TTA), высокое потребление памяти и процессора.
Прежде чем читать дальше, перейдите по ссылке. Попробуйте поиграть пару партий. Играть желательно с десктопа.
Немного истории
С самого начала веб-браузер был задуман как тонкий клиент для веб-серверов. Браузер отображал гипертекстовые страницы, которые получал от сервера. Просто и изящно. Как это часто бывает, красивая идея столкнулась с реальностью, и уже через несколько лет производители браузеров добавили поддержку скриптового языка. Сначала он служил лишь для украшательства и вплоть до середины нулевых хорошим тоном считалось делать веб-страницы работающими без поддержки JS.
Современный подход к разработке веб-сайтов это результат развития требований к интерактивности пользовательского интерфейса. Задачи по улучшению интерактивности легли на плечи верстальщиков. Те зачастую не имели компетенций и полномочий разрабатывать "сквозное" решение. Верстальщики научились писать JS и превратились во фронтендеров. Логика постепенно начала перетекать с сервера на клиент. Фронтендеру удобно писать для браузера, а бекендкеру удобно не думать о пользователе (мое дело тебе JSON отдать, а дальше хоть трава не расти). Буквально два года назад можно было наблюдать всплеск интереса к serverless-архитектуре, где предлагалось что JS-приложения будут напрямую работать с БД и шинами событий.
На данный момент "сферический веб-сайт в вакууме" представляет собой сложное приложение на JS и простой API-сервер с которым оно общается. Основная логика выполняется на толстом клиенте, серверная часть вырождается до простой прослойки к БД.
Необходимость держать логику на клиенте порождает проблемы. Если сервис "взлетел" и стал зарабатывать, то дальше, в плане производительности, ему будет только хуже. Будут меняться требования. Будет меняться команда разработки. Нового кода будет все больше, а старый код не будет вычищаться. Страница распухнет от зависимостей, будет загружать JSON о назначении которого уже никто не помнит, но удалять страшно, вдруг что-то сломается. Будут появляться фоновые задачи setInterval, каждая из которых выполняется по несколько миллисекунд каждую секунду, что через какое-то время приведет к тормозам и разогреву айпада несчастного пользователя до того, что он сможет жарить на нем яичницу. Закончится это тем, что выгоревшие фронтендеры придут к менеджеру с предложением переписать все с нуля на новом фреймворке. Менеджер откажет, и фронтендеры станут использовать два фреймворка совместно.
Как работает Королев
Так вот, что если вернуться к точке отчета? Тому моменту, когда кому-то пришла в голову идея обновлять контент без перезагрузки страницы, и историческая неизбежность породила AJAX? Что если оставить все на сервере и сделать тонкий клиент? Лучшие сайты делают пререндеринг страниц на сервере (SSR), чтобы пользователь видел интерфейс до того как загрузится и запустится JS. Можно пойти дальше и оставить на клиенте только код, который отвечает за обработку ввода-вывода учитывая современные требования к интерактивности. Мысли об этом вылились в проект "Королев".
Как это работает со стороны клиента? Пользователь приходит на страницу. Сервер отдает сформированный HTML и небольшой скрипт (~6 Кбайт без сжатия), который соединяется с сервером по веб-сокету. Когда пользователь производит событие (например клик), скрипт отправляет его на сервер. Обработав событие, сервер формирует список команд вида "добавь новый <div> туда-то", "добавь класс к такому-то элементу", "удали такой-то элемент". Клиент применяет список команд к DOM. Как таковой работы с HTML не происходит — скрипт работает непосредственно с DOM, поэтому не стоит беспокоиться что содержимое формы или позиция скролла будет сброшена.
Что происходит на сервере? Когда от браузера приходит запрос на страницу, Королев создает новую сессию. Для сессии производится начальное состояние, которое сохраняется в кеше. Из этого состояния формируется HTML, который отдается клиенту в качестве ответа на запрос. Кроме этого сервер сохраняет в сессии "виртуальный DOM". После запроса страницы, сервер принимает запрос на открытие веб-сокета. Королев связывает открытый веб-сокет с сессией. Каждое событие приходящее с клиента может изменить состояние связанное с сессией. Каждое изменение состояния приводит к вызову функции render, которая формирует новый "виртуальный DOM", который сравнивается со старой версией. В результате сравнения получается список команд для отправки на клиент.
Что происходит в коде и голове разработчика? Описанное выше могло напомнить вам React, с тем отличием что все выполняется на сервере. С точки зрения подхода к разработке мы так-же имеем что-то подобное. Поэтому, если вы работали с React или другим "виртуальным DOM", то подход Королева будет вам знаком. Если вы не знакомы с React, то представьте что у вас есть данные которые вы вставляете в шаблон. Представьте, что по шаблону раскиданы обработчики событий которые умеют изменять данные (но не DOM). Вы изменяете данные, страница изменяется сама. Королев сам придумывает как изменить DOM.
Производительность
Есть два популярных вопроса по поводу Королева: "что если задержки высокие" и "не нагрузит ли это мой сервер". Оба вопроса весьма резонные. Фронтенд-программист привык что его программа работает на локальной машине пользователя. Это значит что изменения произведенные ей применятся как только JS-машина закончит выполнение кода и браузер начнет рендеренг. Я специально показал пример использования "на максималках" в самом начале. Вы могли наблюдать задержку только если заходили с другой стороны земного шара (сервера расположены в Москве) или сидели в интернете через GPRS. Ну или мой жалкий виртуальный сервак с одним ядром и 1 Гбайт оперативки не выдержал хабра-эффекта.
Вопрос про нагрузку на сервер задают обычно бекендеры. Движок вывода изменений работает очень быстро: ~10 тыс. выводов в секунду для двух произвольных деревьев из 500 узлов на младшем макбуке 2013 года. Статический рендеринг тоже дает довольно хороший результат: до 1 млн. страниц в секунду. Каждый "виртуальный DOM" хранится и обрабатывается в специальном сереализованном виде и занимает 128 Кбайт для средней веб-страницы. Процесс вывода специально оптимизирован и не имеет оверхеда по памяти и GC.
Что касается скорости разработки, то здесь Королев дает большие преимущества. Не нужно писать дополнительную прослойку между БД и сервером. Не нужно согласовывать протокол между клиентом и сервером. Не нужно заботиться о модульности фронтенда — вес JS на клиенте всегда останется одинаковым. Не нужно делать дополнительную логику для серверных событий: просто примите сообщение из очереди и измените состояние сессии, Королев отрендерит и доставит.
Цена
За преимущества придется заплатить. От каких-то привычек придется отказаться, а какие-то новые приобрести. На пример придется отказаться от JS-анимаций и удовлетвориться CSS-анимациями. Придется научиться делать инфраструктуру изначально геораспределенной, если хотите обслуживать пользователей из разных стран качественно. Придется отказаться от JS и перейти на Scala.
Мне немного стыдно (на самом деле нет), что я ввел читателя в заблуждение и не сказал сразу что Королев написан на Scala. Дочитали бы вы до этого момента, если бы я сразу рассказал об этом? Рассказывая о Королеве мне приходится преодолевать два стереотипа. Первый связан с тем что серверный рендеринг воспринимается как что-то медленное, не интерактивное. Второй связан с тем что Scala это что-то сложное. И первый и второй стереотип не имеют к реальности никакого отношения. Более того программировать в стиле React на Scala удобнее чем на JS. Современный JS тяготеет к функциональному программированию, Scala дает его из коробки. На пример, у любого объекта в Scala есть метод copy(), который позволяет скопировать объект изменив некоторые поля. Иммутабельные коллекции встроены в стандартную библотеку Scala.
Заключение
Королев разрабатывается уже три года несколькими разработчиками и многие "детские" проблемы в нем решены. Проект хорошо документирован, вся функциональность покрыта примерами. Предлагаю начинать внедрение Королева с небольших самостоятельных сервисов. Я надеюсь, что Королев поможет сделать программы менее разочаровывающими.
Комментарии (47)
AriesUa
10.06.2019 11:37Это всегда хорошо звучит в начале. Делаем красиво, быстро, стильно, молодежно. Но что делать, если к тебе приходит задача, в которой клиенту надо именно вот так здесь и сейчас — к примеру, здесь должна быть анимация.
За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.
Современная веб разработка, это гибкость к изменениям. Сделать что-то быстро и качественно. (Ну или хотя бы найти компромис).
Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.yelbota Автор
10.06.2019 11:43Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.
О том и разговор. Можно ходить к БД на прямую, к очереди напрямую, к микросервисам напрямую и так далее.
За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.
Кто знает? Может быть клиент готов платить за софт который не тормозит и не выжирает всю память, а менеджер просто не в курсе что так можно было?
JustDont
10.06.2019 11:48Может быть клиент готов платить за софт который не тормозит и не выжирает всю память
Для такого софта не нужен именно серверный рендеринг. Даже «медленное устаревшее завирусованное» устройство уж как-нибудь у себя интерактивную HTML-страничку покажет без особых проблем. Если не нагружать его бессмысленной работой и не заставлять скачивать мегабайты JS. Кстати, у серверной интерактивности и мегабайт JS слабое место одно и то же — при плохом качестве связи первое не работает, а второе — не скачивается.
solver
10.06.2019 12:11Если, если, если, если… У вас очень много условий при который обычный подход к построению web приложений будет хорошо работать.
При плохом качестве интернета проблемы будут разные. Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально. Так что ваше «первое не работает» далеко от истины. Только в каких-то совсем крайних случаях, когда все другие способы давно перестали работать…JustDont
10.06.2019 12:20Если, если, если, если… У вас очень много условий
Да что вы говорите. Мои «много условий» — это «нормально делай, нормально будет». Говнокодом я вам и серверный рендеринг зарою так, что никаких серверов в облаках не хватит.
Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально.
При плохом интернете вас ждут разрывы соединений (это то самое, что не даёт вам скачать 1Мб клиента, если что) — и это означает, что ваши запросы местами не будут уходить на сервер, местами будут тормозить (и разницы между «оборвалось» и «тормозит» вы, как пользователь, не увидите), и местами ответы не будут приходить — потому что не пришли или пришли не полностью.
Работать с «серверной интерактивностью» в таких случаях сложно даже в крайне простых случаях типа ssh.
hssergey
10.06.2019 14:07При плохой мобильной связи может быть еще следующая картина — несколько сообщений от сервера морозятся, морозятся, а потом выпуливаются все сразу. При этом, если клиент просто отображает их по мере прихода, будет выглядеть как будто все висело-висело, а потом что-то резко и быстро начало моргать и переключаться. Я в мобильных играх когда-то на эти грабли уже наступал…
Oniry
10.06.2019 13:52Подобная идея давно имеет реализация в erlang n2o (можно сделать интерактивное приложение без знаний js)
Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».yelbota Автор
10.06.2019 13:59Подобная идея давно имеет реализация в erlang n2o (можно сделать интерактивное приложение без знаний js)
Да, n2o один из источников вдохновения. При всей нелюбви к Максу Сохацкому лично, надо отдать ему должное: в своей работе он воплощает то каким софт должен быть на мой взгляд. В Королеве несколько другой подход к работке.
Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».
Можно. В Королеве для этого предлагается использовать веб-компоненты.
legolegs
10.06.2019 14:54Предположим, весь веб завтра пересядет на Королев. Послезавтра фронтэдеры снова изобретут 123 фреймворка поверх вашего и потащат их все в свои проекты, решая такие бизнес-задачи, как «надо, чтобы буквы плясали», «бэграунд размыт везде, кроме как под курсором» и прочее, что я даже вообразить не в силах.
Вся нагрузка с миллиона раскалённых айпадов в полном объёме переедет на сервер, который от такого расправится и стечёт в подвал.
Проблема с жирным тормозным хрупким вебом не техническая, ИМХО.yelbota Автор
10.06.2019 15:04Вся нагрузка с миллиона раскалённых айпадов в полном объёме переедет на сервер, который от такого расправится и стечёт в подвал.
Но пользователь этого не заметит.
Scf
10.06.2019 16:23Не думали про композитный подход? когда korolev component может содержать css/js? Когда первоначальный рендер происходит на сервере, а динамическое обновление html возможно как по инициативе сервере, так и по инициативе клиента — либо запросом ререндера с сервера, либо прямой манипуляцией DOM.
yelbota Автор
10.06.2019 16:34Для интеграции JS предлагается использовать веб-компоненты. Типичный пример — карты.
YAZART
10.06.2019 18:40Но это ведь вроде как пройденный этап? Если я не ошибаюсь у microsoft был похожий подход, там даже вместо js на c#(или vb) писались скрипты, состояние страницы хранилось фактически на сервере. Ну конечно тогда не было websocket, но не суть. Ведь очень дорого с точки зрения памяти хранить состояние страницы клиента на сервере, если её не хранить, то значит гонять большие массивы данных туда сюда этого состояния. Очевидно что положить такой сервис не составит труда. Сколько памяти приходится на один конекшн(для сервера рендеринга) при таком подходе? Сейчас вам надо поддерживать одно api для всех платформ web ios android. И все быстро работает потому что посылаются только компактно уложенные в json данные. На каждый клик при котором производится взаимодействие лезть на сервер это жесть при нестабильном соединении. При падении сервера, который держал состояние клиента как восстановить состояние?
abramov231
10.06.2019 18:57Зачем тянуть логику рендеринга на сервер, если браузер всё равно будет рендерить? Одно дело первая прорисовка, там это может дать ускорение, но потом то зачем? Хотите сказать отправка и получение данных по сети обойдутся дешевле, чем обработка логики на клиенте? Не знаю какой у вас проект, но по моему 15-летнему опыту такие проекты не попадались ни разу. Везде производительнее рассчитать на сервере только логику, отдав рендеринг на клиентской машине самой клиентской машине. Или я не понял что вы делаете.
Virviil
11.06.2019 09:47+1Вобщем-то подобные тенденции здорово летают в воздухе — и скорее всего займут свою нишу.
Вот недавная статья о подобной технологии на Elixir: https://habr.com/en/post/452724/
Правда там все запихано прямо в наиболее популярный и поддерживаемый фреймворк.
Но всетки трудно не согласится с тем, что анимации будут тормозить, а сервера будут стекать под жесткой нагрузкой. В связи с этим видится разумным разделение логики на данные и отображение, и все-таки передачу туда-сюда только состояния, связанное с данными. Возможно — web components будет действительно лучшим решением для такого разделения.
zugo
11.06.2019 15:12Blazor умеет работать по аналогичной модели.
В .NET Core 3.0 будет из коробки.yelbota Автор
11.06.2019 15:18Судя по описанию 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 достаточно для работы.
zugo
11.06.2019 15:23+1Вы бы все-таки сходили по ссылке.
TL;DR: Там два варианта работы на выбор:
1. Client-side — Mono runtime компилируется в wasm и исполняет C# код в браузере вместо JS. Не особо ценно, кроме как возможностью писать ПЕРЕДНИЙ КОНЕЦ, не шкварясь об JS.
2. И, собственно, server-side — очень тонкая JS-прослойка на клиенте, которая вызывает RPC на сервере через WebSocket, точно так же, как ваш Королев.yelbota Автор
11.06.2019 15:43Действительно. Судя по этой статье разработчики 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.
JustDont
Вы сейчас с чьими фантазиями в чьей голове говорите?
Серверный рендеринг нигде и никем (вменяемым) не воспринимался как «медленное». Это всегда самое что ни на есть быстрое, только процессорные мощности должны быть на 100% ваши. У вас миллион пользователей в секунду и каждому надо посчитать его DOM? Вот и будьте добры считать, без перегрузок и отказов обслуживания.
То же самое с интерактивностью. Если вы пишете нам из 2019 года, то пора бы уж понимать, что в этом году уже много лет можно сделать серверный рендеринг интерактивным без особых проблем. Вопрос — опять же, в процессорных мощностях, которые будут целиком на вашей стороне и должны обслуживать всех клиентов.
Критические проблемы серверного рендеринга не в том, что вы написали, а в масштабируемости (помним про процессорные мощности целиком на вашей стороне) и в неустранимом оверхеде на рендеринг — сервер не владеет информацией о том, что и как нужно рендерить (поскольку не является конечным устройством), и в хоть сколько-нибудь сложных случаях должен сначала получать информацию о конечном устройстве (вплоть до размера окна браузера, если вы, скажем, графику масштабируемую рисуете), а потом генерировать ответ — это лишний блокирующий рендер запрос на сервер, которого принципиально нет в «обычном» фронтэнде и который будет у вас в любых достаточно сложных случаях.
yelbota Автор
На мой взгляд с масштабируемостью серверных мощностей как раз таки проблем нет. У есть есть виртуальные сервера в облаках и мы можем динамически добавлять серверные мощности в случае наплыва пользователь. Достаточно, чтобы сервис умел масштабироваться горизонтально. С другой стороны повлиять на конечное устройство мы не можем. Оно может быть медленным, устаревшим, завирусованым и так далее. Чем слабее мы его нагрузим, тем лучше.
Под «рендерить» подразумевается отображение бизнес-данных в браузерный DOM. Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
JustDont
Ну и к чему тогда у вас там сарказм про глупых фронтэндеров, от безвыходности использующих два фреймворка? У вас тоже — оп, и стало два.
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны. «Тупой» тонкий слой бэка, собирающий что-то там из базы или из нижележащих сервисов, и бэк, который рисует всем их DOM — это совсем разные вычислительные нагрузки.
yelbota Автор
Это не сарказм, а реальное положение дел. В начале пилит Вася, потом к нему присоединяются Петя с Колей, потом Вася увольняется и пошло-поехало. К сожалению разработка выстроена не всегда грамотно. Особенно в стартапах.
Использовать Королев и Реакт совместно довольно проблемно.
Кто-то должен платить. По вашему будет лучше, если заплатить пользователь? Почему мы продолжаем делать веб на PHP, Ruby, Python, а не перейдем, на пример на Rust чтобы платить еще меньше?
Надо замерять. Невозможно сравнить Королев и условный веб-сервер собирающий JSON. Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
JustDont
Ну а у вас реальное положение дел — это «у нас серверный рендеринг! ой, а картинку как-нибудь сами нарисуйте». То есть, настолько же всё плохо.
Дело не в реакте, а в том, что мне надо какое-то второе решение, чтоб картинки на клиенте (подогнанные под клиента) рисовать.
Конечно. Подавляющее большинство пользователей, открывая вашу страничку, делают это на очень неплохих процессорных мощностях. Которые спокойно отрисуют этот ваш DOM и вообще много чего сделают, особенно если делать это вменяемыми способами.
В такой постановке это ни о чём не говорит. Может у вас на каждый клик там два байта обновлений; в такой ситуации «дохлый макбук 2013 года» и с миллионами пользователей сможет справиться.
ЗЫ: Это кстати любопытно, что вы сами гоняете «дохлый макбук 2013 года» как сервер, но при этом считаете, что у пользователей с мощностями всё настолько плохо, что их надо разгружать. В то время как пользователи как раз с подобных систем и будут ваши странички открывать.
solver
Вот с этим, к сожалению, на фронте основные проблемы.
P.S. Т.е. понятно, что не все проекты такие. Но таковых подавляющее большинство.
JustDont
Это не проблемы технологий фронтэнда.
solver
Конечно это не проблемы технологий фронтэнда. Никто этого и не утверждал собственно))
Но проблемы людей, делающих этот самый фронтэнд, по другому просто не решить. Только созданием технологий которые уменьшают появление проблем создаваемых людьми.
В противном случае мы дальше С и С++ просто не ушли. Все бы делали без ошибок на этих языках. А может и дальше ассемблера, кто знает)
yelbota Автор
На каждый клик сравнение двух версий виртуального DOM. 1 млн. CCU это чудовищно много. Такие показатели бывают только у супер-разрекламированных онлайн-игр на запуске. Представим что нормальный сервак держит 10000 CCU. Если уж у вашего сервиса такая популярность, то купить 100 серверов не большая проблема.
vintage
Сортировку списка дрегендропом реализуйте, пожалуйста.
yelbota Автор
То есть игра с анимациями и вот этим всем Вас не убеждает?
vintage
Событие dragover возникает десятки раз в секунду и на каждое нужно синхронно реагировать.
babylon
Для вложенных структур прибавьте бабблинг и капчуринг.
Topchy
Вы придумали очередной велосипед. Все что Вы описали (и даже больше) возможно с помощью react server side rendering
habr.com/post/339148
yelbota Автор
Во-первых, на сколько я понимаю, React не позволяет обрабатывать события на сервере, а предлагает только рендер начального состояния. Во-вторых React 16 вышел на год позже Королева. Хотя в любом случае изобретение не мое. Ниже в комментариях есть ссылка на проект с подобной философией для языка Erlang.
Topchy
1) Можно реализовать. Причем достаточно просто и гибко (можно рендерить покомпонентно на сервере, с какой угодно глубиной вложенности)
2) SSR есть в react с древних версий, в статье по ссылке описаны новые возможности просто.
yelbota Автор
1) Круто! Можно ссылку на пример?
Topchy
Тут можно код посмотреть, ну и основную мысль как запустить события через сервер www.crmarsh.com/react-ssr
Ну и чтобы дальше не развивать — решений может быть много, в т/ч/ прокидывать состояние через react router
yelbota Автор
Из этой статьи не очевидно как реализовать подобное Королеву. Судя по документации ReactDOMServer это и не предполагается. Чтобы работало как в Королеве нужен метод который будет рендерить в список событий для отправки по веб-сокету. При чем он должен выдавать только изменения. Опять же на стороне клиента должен быть механизм, который такие списки будет обрабатывать.
Topchy
А зачем делать подобно Королеву? Есть возможность рендеринга на сервере, есть виртуальный ДОМ. И все это работает, поддерживается и развивается. Просто комбинировать и адаптировать к своему решению.
Предпочитаю идти от потребностей, зачем натягивать сову на глобус?