Мышление и практика внешнего изоморфного рендеринга

Node.js внешний интерфейс

открытие

Связанная архитектура внешнего изоморфного рендеринга дает мне наиболее интуитивное ощущение.Это самое сложное решение для внешнего рендеринга, и это также попытка, которую необходимо предпринять, чтобы добиться максимального пользовательского опыта. внедрение Node.js позволяет В традиционной области внешнего интерфейса SEO-оптимизация больше не является проблемой, но, очевидно, это всего лишь побочные продукты.

вопрос

Бог открывает для нас окно и закрывает для нас дверь.

Известное нам традиционное SPA, одностраничное приложение, чем ближе оно к пользователю, тем сложнее взаимодействие и тем очевиднее его недостатки.JavaScript не принес нам нового опыта и обеспечивает эффективность разработки на основе компонентов.В то же время были забыты недостатки «белого экрана», которые сопровождались различными преимуществами SPA.У нас есть схема хризантемы для покрытия DOM до сборки JavaScript и схема мониторинга белого экрана для улучшения отчетов о реальных пользовательских данных. Но это не затрагивает сути проблемы белого экрана, то есть "построителем DOM является JavaScript, а не нативный браузер".

<html>
  <head><title /></head>
  <body>
  	<div id="root"></div>
    <script src="render.js"></script>
  </body>
</html>

Как показано в приведенном выше коде, в архитектуре SPA сервер напрямую выдает HTML следующим образом.После того, как браузер заканчивает рендеринг узла body#root, область рисования страницы фактически пуста, пока render.js не создаст настоящий DOM. структуру, а затем добавить к #root. В настоящее время,Когда отображается первый экран, это должно быть после завершения запроса render.js через сеть, а затем завершено выполнение JavaScript.

Давайте вернемся в эру оригинального интерфейса. В то время JavaScript не был таким мощным. Наша серверная часть выплевывала весь HTML во внешний интерфейс. Мы использовали jQuery для решения взаимодействия с пользователем. Хотя этот метод имеет много недостатков, нельзя отрицать, что он имеет теоретическое минимальное время белого экрана.

<html>
	<head><title /></head>
  <body>
  	<div id="root">
    	<div class="header">
        <img src="logo.png" />
      </div>
      <div calss="content">
        <div class="shopitem">
        </div>
      </div>
    </div>
  </body>
</html>

Как показано в приведенном выше коде, при прямом рендеринге на сервере браузер напрямую получает окончательный HTML-код, а браузер генерирует и отображает элементы DOM после синтаксического анализа HTML. Таким образом, по сравнению с SPA, рендеринг на стороне сервера интуитивно понятен:

  • Конвертируйте HTML в DOM, браузер сгенерирует DOM за меньшее время, чем JavaScript
  • Исключить запрос JavaScript и время компиляции в SPA

**

решить

Появление Node.js в значительной степени придало больше энергии традиционному внешнему интерфейсу.Разделение внешнего интерфейса также изменилось с разделения физических файлов на ранней стадии на разделение обязанностей. разработчики избавлены от кошмара пейджеров.Теперь JavaScript можно выполнять на стороне сервера.. Наслаждаясь этими дивидендами, мы неосознанно представим себе решение, обладающее большинством преимуществ SPA, но устраняющее большинство его недостатков, то есть серверная сторона выводит HTML, а затем клиентская сторона повторно использует HTML, продолжайте режим SPA, который не только решает проблему белого экрана и SEO, но и наследует пользовательский опыт без обновления и компонентизации разработки.

Ну, если это так, то есть проблема согласованности. Мы должны повторно использовать HTML-вывод сервера на стороне браузера, чтобы избежать адаптации нескольких наборов кодов, в то время как традиционный рендеринг шаблонов возможен, если вы выбираете механизм шаблонов, который поддерживает как браузеры, так и Node.js. Мы пишем шаблон, подготавливаем данные в Node.js, а затем заливаем данные в шаблон для генерации HTML, а после вывода в браузер клиентский JavaScript осуществляет взаимодействие, и дело сделано.

Все проблемы, возникающие при разработке программного обеспечения, можно решить, добавив слой абстракции.

Когда идея здесь, мы обнаружим, что «шаблон» на самом деле является уровнем абстракции.Хотя лежащий в основе HTML может работать только на стороне браузера, шаблон верхнего уровня может работать в браузере и на стороне сервера через механизм шаблонов на одновременно.В вертикальном направлении, в горизонтальном направлении шаблон развязывает данные и структуру, и заливает данные в структуру.Такая заливка фактически является одноразовой транзакцией, и руководству все равно.

С течением времени пришла волна компонентизации.Его основная концепция, Virtual DOM, заставляет разработчиков интерфейса кричать о своей декларативности и высокой производительности, но ее суть заключается в том, чтобы решить проблему частого манипулирования DOM в HTML. абстракции, сделанной выше, отличается от шаблона тем, что он взаимодействует с данными и структурой.Представителями являются поток данных с одним элементом, используемый Facebook, и поток данных MVVM, используемый Vue.Дорога проста, мы наблюдаем функциюUI = F(data), где UI — это окончательный выходной внешний интерфейс, данные — это данные, а F — структура шаблона или виртуальный DOM,Метод шаблона заключается в том, что F выполняется только один раз, а метод компонента выполняется снова каждый раз при изменении данных..

Таким образом, теоретически, будь то шаблонный метод или компонентный метод, интерфейсные и внутренние решения изоморфизма готовы к появлению.Мы получаем данные на стороне Node.js, выполняем F-функцию и получаем HTML-вывод. в браузер. JavaScript браузера повторно использует HTML и продолжает выполнять функцию F, подождите, пока данные изменятся, продолжайте выполнять функцию F, взаимодействие также решено, отлично~~~

воплощать в жизнь

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

Общий код

Поскольку F должен выполняться на стороне браузера и на стороне сервера одновременно, для всего приложения Vue нам необходимо поддерживать оба конца, то есть общий код. Итак, нам нужно преобразовать код архитектуры SPA:

  • Разделен на два входа, разделен на сервер и клиент, вводится только общий код, а затем вызываются соответствующие функции рендеринга в разных средах. Конечно, ReactDOM.render будет генерировать структуру DOM на стороне клиента, а HTML будет генерироваться на стороне сервера с помощью ReactServer.renderToString, который должен быть передан во внешний интерфейс HTTP-сервером, а конкретные проблемы среды будут решены. решается на каждый вход;
  • В общем коде не разрешается ссылаться на DOM, окно вызова, документ, такой как специфичный для браузера, и ссылаться на конкретные операции на стороне сервера, такие как глобальный процесс, без определения среды выполнения, которая часто является основной причиной Node.js. проблемы с обслуживанием;
  • Чтобы быть совместимым с обоими концами, при выборе библиотеки необходимо поддерживать оба конца, например, axios, lodash и т. д.;
  • И у React, и у Vue есть жизненные циклы. Необходимо различать, какие жизненные циклы выполняются в браузере, а какие на стороне сервера или выполняются одновременно. Например, если вы используете такие библиотеки, как Redux или Vuex, это лучше всего ввести хуки asyncData на компоненты для обработки данных запроса, которые используются обеими сторонами одновременно;
  • Определение различных сред выполнения может быть решено путем внедрения process.env.EXEC_ENV следующим образом:
if (process.env.EXEC_ENV === 'client') {
  window.addEventListener(...);
}

if (process.env.EXEC_ENV === 'server') {
}

построить и запустить

  • При использовании веб-пакета для сборки необходимо упаковать общедоступную часть приложения, чтобы сформировать общедоступный код, который импортируется и выполняется сервером, а клиент может ссылаться на упакованный общедоступный код, а затем использовать веб-пакет для его импорта, а затем выполнять специальная обработка;
  • Необходимо ввести средний уровень Node.js, который отвечает за запрос данных, предоставление возможностей рендеринга и предоставление услуг HTTP.Поскольку шаблоны HTML необходимо внедрять на стороне сервера, файлы CDN должны обрабатываться сами по себе;
  • Что касается использования babel, то его вообще можно обрабатывать в браузере, а сервер решает только специальный синтаксис, например jsx, vue template;

Новый мир

На данный момент проблема белого экрана кажется решенной.Помещая логику рендеринга JavaScript на сторону Node.js, мы ускоряем время появления первого экрана.Однако, учитывая мощь Node.js на переднем плане конец, мы можем сделать больше.

Снова поговорим о первом экране

Давайте изменим перспективу немного более внимательно и сосредоточимся на части «вывод HTML со стороны сервера». Скрытый смысл в том, что нам нужно вывести весь HTML, отображаемый приложением, на внешний интерфейс. На самом деле это не так. , Например:

Например, есть страница на мобильной стороне, которая имеет высоту около 10 экранов.Если мы выводим все 10 экранов на стороне сервера, то это на самом деле немного расточительно.Мы можем вывести только то, что нужно первому экрану, тем самым сократить время выполнения рендеринга и, следовательно, время TTFB. Позвольте странице быстрее попасть в поле зрения пользователя. На практике общая ситуация такова, что вывод происходит примерно на два экрана быстрее, что может справиться с проблемой высоты всех моделей.Остальные 8 экранов продолжают рендериться на стороне браузера, и контент создается постепенно, а пользователь не воспринимать его.

контроль ресурсов

Благодаря еще одному смыслу вывода HTML в Node.js, мы можем воспринимать клиента сразу при первом контакте, и у нас достаточно гибкости.Возьмем другой пример:

Для платформы Android и платформы iOS существует другой скрипт, который нужно только загрузить.В случае SPA нам нужно только дождаться выполнения JavaScript, когда мы определяем navigation.userAgent, чтобы узнать, какая платформа является первой, а затем appendChild скрипт в тело, но если на стороне сервера Это может быть воспринято при первом контакте. Мы можем напрямую получить платформу суждения userAgent в HTTP-запросе на стороне сервера, и обработать его в шаблоне в соответствии с логотипом. Очевидно, это очень стабильно.

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

управление кешем

Общий бизнес-сценарий, нам нужно получить сетевые данные Node.js, а затем визуализировать HTML с помощью функции (обычно включаемой в данные, необходимые для вывода HTML для повторного использования), на этот раз мы можем обратиться к просмотрам страниц после генерация HTML-строки и создание кэша политик, кэш (и другие программы, обычно выбираемые Redis), непосредственно рядом с той же страницей, выводимой непосредственно на внешний интерфейс,Значительно повышает производительность рендеринга.

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

  • Широта адреса страницы, по разным адресам, вывод HTML несовместим, поэтому URL-адрес можно использовать как один из элементов ключа;
  • Если вы не вошли в систему, страница может быть кэширована напрямую, если вам нужно определить специфику платформы, вам нужно обработать ее на стороне Node.js;
  • В состоянии входа в систему, если HTML-код вошедшего в систему пользователя был кэширован, вам необходимо стереть и заменить компоненты, связанные с входом в систему, или напрямую предоставить страницу в состоянии входа в систему для внесения изменений на клиенте сторона.

испытание

Изоморфный рендеринг выглядит хорошо, но у него больше проблем, чем у традиционного SPA:

Node.js

Рендеринг на стороне сервера соответствует традиционным приложениям Node.js.Функция renderToString не только интенсивно использует процессор, но и требует разных машинных ресурсов для разных компонентов.Для этого требуется мониторинг индикаторов Node.js, запись журнала, сбор ошибок, совершенство аварийный механизм. Дополнительным ключевым показателем здесь является время renderToString, которое отражает время, используемое для рендеринга Node.js.Если добавлен механизм кэширования, необходимо подсчитывать частоту попаданий и т. д.

качество кода

Что касается написания кода общего назначения, то требования к разработчикам выше, чем архитектура SPA.Нам нужно быть внимательными и осторожными, так как если мы будем делать ошибки, то это приведет к утечкам памяти и всплескам ЦП, которые трудно устранить, и однажды возникает проблема, это очень сложно, как ремонт самолета, летящего в небе. Я до сих пор помню всплеск памяти, вызванный написанием кода, связанного с браузером, в componentWillMount, и всплеск ЦП, вызванный JSON.stringify большого объекта, что невыносимо. В этом отношении алинода хорошо справляется со своей задачей и действительно может соответствовать этому авиационному сценарию.

Эпилог

Ради эффективности интерфейсы приложили огромные усилия.Будь то инструменты производства, которые мы используем всеми средствами в разработке, или внедрение компонентов, мы решаем эффективность разработки, будь то внедрение Virtual DOM. для решения часто используемого DOM или использования. Чтобы улучшить взаимодействие с пользователем и использовать архитектуру SPA, мы решаем эффективность пользователя и производительность интерфейса. Изоморфный рендеринг также является таким решением, которое привносит сложность Node.js и требует от нас написания более строгого кода.Основная цель состоит в том, чтобы позволить пользователям увидеть страницу быстрее и раньше, даже если это 50 миллисекунд, даже 10 миллисекунд. .

насчет нас

МыТехническая группа Ant Insurance Experience, от Ant Financial Insurance Group. Мы молодая команда (без бремени исторического стека технологий), текущий средний возраст 92 года (убрать самый высокий балл 8х лет - лидер команды, убрать самый низкий балл 97 лет - брат стажер). Мы поддерживаем практически весь страховой бизнес Ali Group. В 2018 году созданное нами общее сокровище произвело фурор в страховой отрасли, а в 2019 году мы готовили и реализовывали несколько крупных проектов. Теперь, с быстрым развитием бизнес-группы, команда также быстро расширяется.Приглашаем всех мастеров фронтенда присоединиться к нам~

Мы надеемся, что вы обладаете: прочной технической базой, глубокими знаниями в определенной области (узлы/интерактивный маркетинг/визуализация данных и т. д.); способны быстро и непрерывно учиться в процессе обучения; оптимистичны, веселы, живы и общительны.

Если вы заинтересованы в том, чтобы присоединиться к нам, пожалуйста, отправьте свое резюме по электронной почте: luguang.ylg@antfin.com

Автор этой статьи: Ant Insurance - Experience Technology Group - Moon Shadow

Адрес Наггетс:Уиллоу Банк Соус

Категории