Есть ли реальный профит от изоморфных приложений?

Question

[Дмитрий]

Нужны мысли вслух от тех, кто реально занимается этим вопросом -))). После ряда экспериментов, пришел к выводу, что как ни ёрзай, а скорость работы приложения значительно падает, если делаем его изоморфным. Пробовал всякие связки, результат один - классический SPA работает намного быстрее, чем изоморф. Причины понятны - во первых увеличение ядра, во вторых периодическая перерисовка целых страниц.
При этом не составляет большого труда отрисовать неверстанные вьюхи для отдачи роботам, а юзеру отдавать классический SPA . Если сделать всё правильно, эту неверстанную вьюху реальный юзер не увидит, увидит сразу спиннер в крайнем случае. К тому-же в эти вьюхи для сео можно что-то дополнительно напихать. Так вот вопрос ко всем. Оно того стоит реально, делать изоморф вместо SPA + неверстанные вьюхи на сервере? В чем профит?

Answer 1

[Сергей Протько]

скорость работы приложения значительно падает, если делаем его изоморфным

В чем выражается? Как делали замеры? Почему медленнее?

классический SPA работает намного быстрее, чем изоморф

Разницы быть не должно вообще.

Причины понятны - во первых увеличение ядра, во вторых периодическая перерисовка целых страниц.

Опять же, ваше изоморфное приложение немного странное, по сути это должно влиять только на первую загрузку, затем все должно работать как SPA, никаких перезагрузок.

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

Ну как бы тот же гугл учитывает стили при ранжировании (адаптация под мобильники и т.д.)

В чем профит?

Изоморфность нужна только для того, что бы уменьшить время отрисовки UI. То есть время между первым запросом и отрисовкой UI должно быть минимально. То что JS подгрузится секундой-двумя позже - это уже незначительная проблема, пользователь скорее всего первые секунды будет разбираться что он хочет делать дальше.

Comments

[Дмитрий]

При изоморфе я отдаю юзеру целиком страницу при первой загрузке. Её надо при этом сначала отрендерить полностью на сервере, и потом отдать. Без этого, я сразу отдаю юзеру то, что хочу, остальное отправляю в ленивую загрузку. В результате при изоморфе первая страница грузится 6-7 секунд. Это жопа. Возможно я просто все неправильно делаю, но пробовал несколько вариантов создания изоморфа (самый быстрый у меня получился на связке redux-reax-express ). Далее. Я никак не вдуплю, как использовать ленивую загрузку и при этом не делать отдельные куски кода для клиента и для сервера. А если делать раздельно, то вообще этот геморой того не стоит, ибо я на какомнить twige или blade или (вставить нужное) раз в 10 быстрее сделаю то, что хочу отдать роботам.

[Сергей Протько]

Дмитрий:

первая страница грузится 6-7 секунд. Это жопа.

что является узким местом не смотрели? Почему так долго? У вас же в принципе приложение там загружено, нужно всего-то загрузить данные из API и отрендрить строку, что в случае с react должно занимать милисекунды.

[Дмитрий]

Сергей Протько: Так сервера же ждёт, там пока отрендерит, подготовит полностью, только потом отдает.

[Сергей Протько]

Дмитрий: и? запросы в апишку - в среднем это где-то где-то 2-3 запроса на скрин, каждый по 100 милисекунд (если вас парит производительность, бэкэнд тоже должен быть шустрым), причем обычно они выполняются паралельно и можно для половины использовать кэш.

Рендеринг же компонентов должен занимать еще парочку милисекунд. Либо же у вас где-то есть узкое место. Ну и непонятно чего ждет сервер.

[Дмитрий]

Сергей Протько: Хм... спасибо за наводку, проблема похоже действительно в самом сервере на ноде. Я дурак грешил не туда всё время.... Страница начинает генерироваться с задержкой 5-6 секунд...
Буду копать.

[Сергей Протько]

Дмитрий: напишите если чего найдете, интересно

[copal]

Разницы быть не должно вообще.

вообще разница обязана быть.. Для примера запросы на клиенте и на сервере разные. По этому библиотеки приводят к единому интерфейсу, что как минимум добавляет по одной лишней функции. И это просто самый минимальный-вымышленный минимум, на деле, как мне кажется намного больше.

[Сергей Протько]

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

Если бы разница была - в "изоморфности" вообще нет никакого смысла.

[copal]

Сергей Протько: Вы наверное не поняли... Вот смотрите - я взял и на клиенте написал new XMLHttpRequest() и сделал запрос. На сервере я пишу http.request() и делаю запрос.
Но теперь мы говорим об изоморфности, то в свою очередь означает что запросы должны быть везде одинаковы. Понимаете? По этому я создаю свою библиотеку с едином интерфейсом request, а уже в зависимости от стороны он будет создавать конкретный экземпляр который будет реализовывать метод request. получается лишний вызов request(){return XMLHttpRequest()} и request(){return http.request()}

[Сергей Протько]

copal: dependency inversion. Рассмотрим на примере Angular2.

Angular предоставляет мне сервис для работы с HTTP и я завязываюсь на его интерфейс. У этого сервиса есть две реализации - для браузера через XmlHttpRequest и для сервера. В зависимости от окружения подтягивается нужный сервис.

Вывод - мой код просто использует сервис, и его не парит как именно происходил запрос. Мой код от этого не меняется вообще.

[Сергей Протько]

copal: Та же история и с роутером. В браузере мы завязаны на window.location, а на ноде - на request.

[Сергей Протько]

copal: но это все - детали реализации внешних зависимостей, фреймворка. Наш код это вообще не парит.

[Артем Кустиков]

copal: клиентский XMLHttpRequest() и серверный http.request() - это не изоморф, а говнокод. Если бы в реальном проекте увидел такую хрень - сразу по рукам чем-нить тяжелым.
Нормальный изоморф работает со своими данными и серверным рендерингом оптимизирует раунд-трипы SPA за страничными данными. И уже только за счет замены нескольких HTTP запросов на один он будет намного быстрее.

[copal]

Артем Кустиков: Вы о чем вообще? У Вас личный js и личный nodejs, который писали только для Вас и в нем есть какие-то другие методы для запросов?

[Артем Кустиков]

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

[copal]

Артем Кустиков: ваще типо подождите? а, че?

[Сергей Протько]

Артем Кустиков: обычно запросы происходят на тот же сервер, а это невилирует лэтенси сети (а так же нет ограничений по количеству одновременных запросов и т.д, да и в пределах loopback интерфейсов MTU намного выше. Ну и да, кеширование тоже штука полезная.

[Сергей Протько]

Артем Кустиков: это не диагноз, это способ оптимизации без дополнительного оверхэда в плане реализации бэкэнда, без увеличения связанности клиента и сервера. Могу заявлять, что способ этот более чем адекватный и рабочий как full-stack разработчик (то есть я пишу и апишки и клиент). Так же есть еще парочка хитростей, вроде мультиплексирования запросов и т.д.

[Артем Кустиков]

Сергей Протько: Набор слов, архитектура бекенда с запросами на http.request в момент генерации базовой страницы - пародия на изоморф. И никакой HTTP2 и кеш тут не спасет.
"Страница начинает генериться через 5 секунд после запроса" - это лучшая характеристика "фуллстэк" девелопера ;-(
Говнокод, в общем, курить гугл "архитектура изоморфных приложений"

[Артем Кустиков]

Ну и ссылочка с описанием "как надо делать изоморф":
www.slideshare.net/spikebrehm/a-28174727

[Сергей Протько]

Артем Кустиков: у меня страница генерится за 100-200 милисекунд. И под "мультиплексированием" я подразумевал не HTTP2, а просто отдельный эндпоинт апишки который в один запрос достает мне данные для нескольких запросов, агрегация данных и т.д. Это можно сделать посредствам мидлвэров и таким образом невилировать время на бутстраппинг приложения (я еще и на PHP апишки пишу, ага).

Использовать http.request на сервере - нормальная практика, особенно в рамках MVP. Когда нагрузки начинают расти можно уже на zeromq переключиться и т.д, нам в принципе без разницы ибо все закрыто абстракцией и подменить реализацию мы можем в любой момент.

Суть в том что "оптимизации" надо применять не потому что так "правильно", а потому что проблемы возникают. Скажем с экономической точки зрения, проще не менять реализацию сервера, а просто быстренько написать адаптер для ноды. Это можно сделать за пару часов и невилировать лэтенси сети при первоначальной загрузке данных, что уже дает существенный прирост производительности. А уже потом можно поставить реверс-прокси кэши, заменить http на zeromq+messagepack и т.д. Но обычно даже это уже не нужно.

[Артем Кустиков]

"Использовать http.request на сервере - нормальная практика..." - это костыль который свидетельствует об отсутствии нормального state management в приложении.
В тестах http.request прикрутить (без других костылей) уже не получится. Итог - костыльный говнокод.

zeromq и прочее к рендерингу вообще никак.

Тот же ReactDOMServer.renderToString - синхронный метод => никакие http.request туды впихнуть не получится, значит все данные надо иметь уже в готовом виде.

var state = evaluateStateBasedOnRequestUrl();
var el = ;
return ReactDOMServer.renderToString(el)

[Сергей Протько]

Артем Кустиков: данные нужно иметь в готовом виде, именно так. А вот http.request - это как раз таки надо что бы эти данные получить. Собственно с этим нет абсолютно никаких проблем и именно об этом и нужно думать когда проектируешь изоморфное приложение. Работа с состоянием полностью отделено от представления.

Answer 2

[uvelichitel]

Нет. Реального профита нет. Но это будущее. Сервер должен предоставлять любой сервис - голые даннные, запакованные данные, рендеринг html, специфицированные вычисления.

Comments

[Артем Кустиков]

Учи матчасть (с)

Один HTTP запрос возвращающий разметку и данные будет всегда быстрее, чем загрузка базового SPA, клиентский рендеринг/последующий запрос за данными/повторный рендеринг
Проблема с изоморфами не в "профите", а в увеличенной нагрузке на сервер, но и это можно порешать