Рендеринг на стороне сервера с Nuxt.js

внешний интерфейс сервер Vue.js Nuxt.js
Рендеринг на стороне сервера с Nuxt.js

Из истории фронтенд-разработки, рендеринга на стороне сервера

Некоторое время назад я увидел вопрос на Zhihu, в котором говорилось, почему рендеринг HTML на стороне сервера снова становится популярным. Разобрал некоторые комментарии в интернете, совместил с собственными идеями, разобрал историю разработки фронтенда.

Еще в 1989 году физик создал рождение HTML для облегчения обмена академическими документами, и это также время, когда зародился внешний интерфейс. Позже к фронтенду присоединились CSS и Javascript для рендеринга стилей страниц и обработки логики анимации страниц, и были созданы три мушкетёра. Программисты внешнего интерфейса в самом начале выполняют всю основную работу, такую ​​как нарезка графики и стилей написания (CSS) и специальные эффекты страницы (JS), и они находятся в нижней части цепочки презрения программиста.
С развитием Интернета и технического прогресса статические страницы уже не в состоянии удовлетворить потребности продукта, и динамические данные должны генерироваться на странице согласно логике. Рендеринг сервера в настоящее время основан на «документе» как на основной идее. Логика на стороне сервера состоит в том, чтобы рассматривать HTML, CSS и JS как статический файл.Нет разницы между «инструкциями» и «данными» для «документов», все является данными. Таким образом, мы видим, что серверный рендеринг, GET — это запрос файла, а одним из самых основных компонентов многих серверных фреймворков в эпоху Web 1.0 являются шаблоны документов, такие как asp, JSP и т. д. Основная концепция дизайна заключается в следующем. для размещения заполнителей в файлах HTML.Затем символы заменяются логикой на стороне сервера фактическими данными, а затем возвращаются. Многие малые и средние проекты, независимо от фронтенда и бэкэнда, полностью состоят из инженеров веб-разработки, которых, согласно современной поговорке, называют инженерами полного стека. Но сейчас с этой моделью много проблем, возьмем в качестве примера jsp, динамические ресурсы и статические ресурсы полностью связаны, сервер находится под большой нагрузкой, и как только возникает ситуация, фронт и бэкэнд играют вместе, и взаимодействие с пользователем крайне плохое; jsp должен работать на веб-сервере, поддерживающем java, производительность не может быть улучшена; если в jsp много контента, ответ страницы будет очень медленным...
В 1998 году в IE5.0 была представлена ​​технология XMLHttpRequest, реализующая функцию асинхронного обращения к серверу, в 2005 году Google использовала асинхронную связь ajax в своем знаменитом интерактивном приложении, а веб-интерфейс привел к революции 2.0. После этого W3C выпустил стандарт XMLHttpRequest, который послужил технической основой для последующей вспышки ajax.
В 2006 году была выпущена библиотека инструментов JQuery, и сразу после ее рождения она покорила мир своими простыми в использовании функциями и способностью решать проблемы совместимости с браузерами.
В 2010 году родился Backbone, была выпущена первая версия RequireJS, и официально наступила эра модульной фронтенд-разработки. Затем, с появлением интерфейса MVC, SPA (одностраничное приложение) стало тенденцией разработки проектов, и разделение труда между интерфейсом и сервером стало очень четким. Внешний интерфейс работает на стороне браузера, а задний — на стороне сервера. Четкое разделение труда допускает параллельную разработку, моделирование тестовых данных не составляет труда, а интерфейс можно разрабатывать локально. В настоящее время среди крупных компаний растет движение по разделению интерфейсов и серверов, а интерфейсы являются независимыми и развиваются независимо. Пришла возможность перевернуться фронтенд-программистам.
Однако в настоящее время многие вещи, которые не должны были превращаться в SPA, также были превращены в SPA. Однако в SPA-приложениях есть разные проблемы, такие как SEO, например, скорость загрузки первого экрана, что заставляет фронтенд-разработчиков беспокоиться об оптимизации.
С появлением Node.js у Javascript появилась возможность работать на стороне сервера, а это означает, что появилась новая модель разработки: интерфейсный уровень пользовательского интерфейса обрабатывает логику представления уровня браузера, а внутренний уровень пользовательского интерфейса обрабатывает маршрутизация, шаблоны, сбор данных, файлы cookie и т. д. С помощью Node уровень веб-сервера также представляет собой код JavaScript, а это означает, что некоторые коды можно повторно использовать до и после. Сценарии, требующие SEO, могут обрабатываться синхронно на стороне сервера. Проблемы с производительностью, вызванные слишком большим количеством асинхронных запросов, также могут быть смягчены с помощью со стороны сервера. Эта модель почти полностью устраняет недостатки предыдущей модели.
Суть крупнейшей идеологической революции в эпоху Web 2.0 не в том, чтобы разделить интерфейс и сервер, а в том, чтобы рассматривать веб-страницы как независимые приложения (приложения). Разделение передней и задней частей — просто неизбежное следствие реализации этой новой архитектуры. Инструкции и данные отделены от программы. HTTP GET получает не отображаемую веб-страницу, а приложение, состоящее из html и Javascript, которое использует браузер в качестве виртуальной машины. Загрузка и отображение данных — это рабочая логика после запуска приложения. Как традиционно называется приложение? Он называется Клиент, который является интерфейсом. Таким образом, интерфейс и серверная часть разделены таким образом, браузер становится рабочей средой приложения, а серверная часть вырождается в простую бизнес-логику и интерфейс данных. Написание Javascript больше не трюк для добавления спецэффектов к веб-страницам, а серьезный проект, такой как написание настольных приложений. Итак, мы увидели фронтенд-инжиниринг, компиляцию (перевод), различные фреймворки MVC/MVVM, инструменты для работы с зависимостями и так далее.

Зачем использовать рендеринг на стороне сервера?

Основная проблема использования рендеринга на стороне сервера — это собственно решение проблемы SEO. Если приложение SPA также имеет хорошее SEO, рендеринг на стороне сервера не так проблематичен. Конечно, проблема скорости загрузки на первом экране, которую может решить серверный рендеринг, тоже одна из причин. Итак, что такое SEO?
SEO (поисковая оптимизация), поисковая оптимизация. Например, Google и Baidu необходимо сканировать публикуемую вами информацию веб-сайта для естественной сортировки, которая выполняется с помощью поисковых роботов.
Давайте посмотрим на два фрагмента кода:

Выше приведен код сканера двух статей Nuggets, написанных очень давно (письмо немного низковато).Общая идея состоит в том, чтобы использовать суперагент для отправки http-запроса, сканировать всю страницу (объект документа), включая заголовок , body и т. д., а затем использовать cheerio для синтаксического анализа, а затем получить элементы узла страницы и ключевую информацию. Может быть вы думаете, что это просто, информация на моей странице запрашивается через ajax, а затем вставляется в элемент dom. Обратите внимание, что страница, просканированная сканером, не отправляет запрос Ajax, это инициализированная чистая статическая страница.Если вы используете спа-приложение, в теле может быть ничего, кроме узла с идентификатором приложения. Поэтому нам нужно, чтобы страница отрисовывалась на стороне сервера, а когда она передается клиенту, это уже статический html-документ с информацией о данных. Конечно, есть и решения для SEO-оптимизации SPA-приложений, которые выходят за рамки этой статьи.
Вот обзор некоторых преимуществ и недостатков серверного рендеринга:

преимущество

  • Хорошо для SEO.
  • Выше сгиба загружается быстро. Поскольку ссылки SPA должны получать все ресурсы на первом экране, а рендеринг на стороне сервера напрямую берет готовый продукт и отображает его.
  • Никаких ресурсов на стороне клиента не требуется. Работа по разбору шаблона передается серверу, который занимает меньше ресурсов на стороне клиента, особенно мобильного терминала, а также позволяет экономить больше энергии.

недостаток

  • Занять ресурсы сервера. На стороне сервера завершается парсинг html шаблона, если запросов много, то это вызовет определенное давление доступа к серверу. И если это внешний рендеринг, он распределяет эти нагрузки на внешний интерфейс.
  • Это не способствует разделению фронта и тыла.

VUE SSR

Универсальный (также известный как изоморфный) JavaScript стал термином, который очень часто используется в сообществе JavaScript. Общий JavaScript используется для описания кода Javascript, который может выполняться как на стороне клиента, так и на стороне сервера. В официальной документации VUE это описано так:

Vue.js — это фреймворк для создания клиентских приложений. По умолчанию компоненты Vue могут выводиться в браузере для создания DOM и управления DOM. Однако также возможно визуализировать тот же компонент в виде строк HTML на стороне сервера, отправить их непосредственно в браузер и, наконец, «смешать» статическую разметку в полностью интерактивное приложение на стороне клиента.

Первую половину предложения легко понять, что означает, что вы можете использовать vue.js для создания компонентов и страниц в серверной (бэкэнд) среде, а затем передать обработанную статическую строку html клиенту для отображения. Во второй половине предложения чувствуется, что предложение не очень гладкое.Английская версия выглядит следующим образом:

«Наконец-то «гидратируйте» статическую разметку в полностью интерактивное приложение на клиенте».

Это, вероятно, означает, что после того, как приложение будет передано клиенту, из-за некоторых статических тегов у клиента будет такое же взаимодействие (то есть двусторонняя привязка данных MVVM).

На схеме этапов построения, приведенной на официальном сайте, также видно, что как для клиентских, так и для серверных приложений мы должны использовать веб-пакет для упаковки — серверу нужен «серверный пакет», а затем он используется для рендеринга на стороне сервера (SSR), и "клиентский" конечный пакет" отправляется в браузер для смешивания статической разметки. Эта статья не углубляетсяVue SSRВ качестве оригинального контента Vue официально рекомендует отличный проект сообщества Nuxt.js, который обеспечивает очень хороший опыт разработки серверного рендеринга Vue.Мы в основном будем обсуждать его.

Nuxt.js

Что такое Nuxt.js?

Создание серверных программ JavaScript несколько скучно и требует большой базовой настройки, прежде чем вы начнете программировать. Поэтому родился Nuxt.js, который решает проблему рендеринга на стороне сервера vue.js. Nuxt.js — это универсальная платформа приложений, основанная на Vue.js. Предустановлены различные конфигурации, необходимые для рендеринга на стороне сервера, такие как асинхронные данные, промежуточное ПО и маршрутизация.Если вы следуете правилам, вы можете легко внедрить SSR. . Это как Angular Universal для Angular, а Next.js для React. Nuxt.js фокусируется в первую очередь на рендеринге пользовательского интерфейса приложений, абстрагируя инфраструктуру клиент/сервер.

Что может Nuxt.js

  • Не нужно беспокоиться о маршрутизации, просто создайте файлы .vue в соответствии с соответствующим уровнем папки.
  • Нет необходимости учитывать проблемы с передачей данных, nuxt будет запрашивать данные асинхронно перед выводом шаблона (необходимо ввести библиотеку axios) и имеет дополнительную инкапсуляцию vuex.
  • Встроенный веб-пакет, пропуская этапы настройки веб-пакета, nuxt упакует соответствующие файлы в соответствии с конфигурацией.

Установите и запустите Nuxt.js

При установленном vue-cli команда для быстрого создания проекта nuxt выглядит следующим образом:

$ vue init nuxt-community/starter-template <project-name>

После входа в каталог проекта

$ npm install

затем запустите проект

$ npm run dev

чтобы проект мог нормально работать вhttp://localhost:3000охватывать

Практическое введение в Nuxt.js

Я не буду подробно описывать некоторые способы использования и API nuxt.js, вы можете непосредственно ознакомиться с руководством на официальном сайте:zh.nuxtjs.org/guide.
Я сделал простую демонстрацию nuxt.js самостоятельно (очень просто),адрес гитхаба, вот кое-что из моего собственного опыта по сравнению со спа-приложениями, чтобы рассказать об этом фреймворке.

1. Структура каталогов Nuxt.js

Nuxt — это шаблон, созданный vue-cli, по сравнению с обычными шаблонами vue у них есть очень важный момент: удобство. nuxt.js также позаботился о конфигурации веб-пакета, необходимой для различных проектов, из коробки, и в основном никаких изменений не требуется. И даже если вам нужно настроить какую-то конфигурацию, ее очень просто изменить. Давайте сравним его структуру каталогов с приложением SPA.

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

  • layouts используются для размещения макетов страниц.
  • Промежуточное программное обеспечение используется для размещения некоторого промежуточного программного обеспечения, мы можем ссылаться на это промежуточное программное обеспечение в компоненте страницы, и логика в нем будет выполняться первой при выполнении логики страницы.
  • Страницы — это место, где размещены все компоненты нашей страницы.Однако, в отличие от спа-приложения, страница в nuxt будет генерировать соответствующие маршруты в соответствии со структурой файлов и папок.Например, структура каталогов в папке моей страницы выглядит следующим образом
pages/
--| _slug/
-----| comments.vue
-----| index.vue
--| users/
-----| _id.vue
--| index.vue

Соответствующая таблица конфигурации маршрутизации, созданная Nuxt.js:

router: {
  routes: [
    {
      name: 'index',
      path: '/',
      component: 'pages/index.vue'
    },
    {
      name: 'users-id',
      path: '/users/:id?',
      component: 'pages/users/_id.vue'
    },
    {
      name: 'slug',
      path: '/:slug',
      component: 'pages/_slug/index.vue'
    },
    {
      name: 'slug-comments',
      path: '/:slug/comments',
      component: 'pages/_slug/comments.vue'
    }
  ]
}
  • plugins централизованно размещают некоторые плагины, такие как axios и т.д.
  • Хранилище — это централизованно определенное дерево состояний. nuxt.js имеет встроенный vuex, здесь нужно определить только одинindex.js, а затем открыть экземпляр Vuex.Store для внешнего мира. Однако после наступления на яму дерево состояний здесь несколько отличается от того, что было в SPA, о котором речь пойдет дальше.

2. Компоненты страницы Nuxt.js

Из сравнения одностраничного файла Nuxt.js и SPA .vue на приведенном выше рисунке, в дополнение к общим атрибутам экземпляра в общем одностраничном файле .vue (таким как данные, методы, свойства и т. д.), Nuxt .js также обеспечивает много удобства Еще одно интересное свойство, которое является одной из самых больших особенностей Nuxt.js.

  1. Во всем процессе выполнения внутри nuxt первое, что нужно пройти, — это управление состоянием.actionsФункция nuxtServerInit в , об этом мы поговорим позже.
  2. затем пройти черезmiddlewareВ функции промежуточного программного обеспечения в настоящее время сбор данных и рендеринг страницы не выполнялись, поэтому мы можем выполнить некоторую логику перед вводом маршрута в функцию промежуточного программного обеспечения, например, оценку разрешений пользователя.
  3. После этого получаются данные страницы.Результаты asyncData и data в принципе совпадают.Можно напрямую вызвать интерфейс сервера.Например, axios отправляет http запрос на получение исходных данных требуемых страницей,а потом возвращает их в виде объекта.В настоящее время объект Vue все еще не создан, поэтому его нельзя вызвать в asyncDatathis.
  4. Выборка в основном используется для заполнения данных дерева состояний (хранилища).
  5. После того, как все это будет сделано, начните создавать экземпляр объекта Vue. Логика здесь такая же, как и в одностраничном приложении. После сборки всего страничного приложения nuxt.js вернет приложение во внешний интерфейс. Обратите внимание, что здесь возвращается не простая страница, а приложение. В настоящее время некоторые свойства частичного спа-приложения на странице, такие как двусторонняя привязка данных мониторинга.
  6. После того, как страница попадает во внешний интерфейс, она начинает выполнять соответствующую логику монтирования.
    Помимо потока выполнения приложения, давайте взглянем на модуль рендеринга страницы.
  • headНекоторые могут настраивать информацию заголовка текущей страницы, такую ​​как заголовок, метаданные и так далее. Конечно, если вам нужно определить глобальную голову, вы можетеnuxt.config.jsв конфигурации.
  • layoutЧасть макета страницы можно настроить, а статические части верхнего и нижнего колонтитула, общие для многих страниц, можно единообразно определить и ссылаться на них по запросу.
  • scrollToTopИспользуется для прокрутки страницы вверх при переходе страницы.
  • transitionАнимация перехода для перехода между страницами.

3. Дерево состояний Vuex

После того, как вся демонстрация завершена, больше всего меня впечатляет дерево состояний, которое отличается от приложения SPA.
То, что мне нужно было сделать в то время, было,Сохраните информацию о пользователе и используйте ее на любой странице. Если информация о пользователе не получена на странице без входа, вернитесь на страницу входа.
Сначала моя дизайнерская идея заключалась в том, что после того, как пользователь успешно войдет в систему, вызовите фоновый интерфейс, чтобы получить всю информацию о пользователе и сохранить ее в хранилище. Блок-схема выглядит следующим образом:

Согласно ситуации с приложением SPA, данные в магазине должны быть разделены между компонентами страницы. Однако обнаружено, что после перехода страницы в Nuxt все дерево состояний Vuex будет сброшено, а исходная информация о пользователе будет потеряна. Из этого можно сделать вывод, что страницы с разными маршрутами являются независимым приложением, и они не разделяют данные в состоянии.
На этот раз я подумал о локальном хранилище сеансов localStorage, поскольку логика доступа из хранилища в исходном процессе изменена на логику из localStorage. Этот метод выполним, но таким образом Vuex не чувствует себя сильным (в этом должно быть что-то странное), и невозможно использовать серверный уровень для управления логикой, такой как истечение срока действия сеанса.
Позже было обнаружено, что в действии в vuex, отрендеренном сервером, предусмотрен метод:nuxtServerInit. Когда Nuxt.js вызывает его, он передает объект контекста страницы в качестве второго параметра, и объект контекста может быть полученreqЗапросить объект, тут такая логика. Я могу сохранить информацию о пользователе в сеансе сервера, а затем передатьreq.session.userдля доступа к текущему зарегистрированному пользователю. Передайте информацию для входа пользователя в дерево состояний клиента, код выглядит следующим образом:

actions: {
  nuxtServerInit ({ commit }, { req }) {
    if (req.session.user) {
      commit('user', req.session.user)
    }
  }
}

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

4. Другое, связанное с Nuxt.js

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

Суммировать

Используйте Vue, React и другие рендеринга сервера, чтобы не перейти до старого рендеринга шаблона. Он скрестил историю, к развитию лучшего. И nuxt.js, все еще очень молодые рамки (версия 0.10.7 теперь является официальным веб-сайтом), в настоящее время существует множество проблем, которые необходимо улучшить, но его присутствие - разработчики Vue.js для создания программы рендеринга на бокосе серверов предоставляет отличное удобство Отказ Я слышал NUXT.JS 2.0, придет, посмотрите после выпуска, может принести нам более полезные новые функции.

Категории