Принципы, стратегии и клиентская сторона

Если вы веб-разработчик, рано или поздно вам нужно перейти на «серверную сторону вещей» и понять, что там происходит и как составить идеальную пару с клиентской стороной (браузером).

Определение SSR и CSR

Итак, мы собираемся начать с определения того, что такое SSR (рендеринг на стороне сервера) в отличие от CSR (рендеринг на стороне клиента).

  • SSR: процесс, при котором пользователь запрашивает у сервера некоторый URL-адрес, например: https://www.mywebsite.com/how-to-ssr, и сервер отвечает. с файлом html, как показано на изображении выше. Все очень просто, поэтому помните: всякий раз, когда кто-то из ваших коллег или в какой-то статье говорят о SSR, не бойтесь: в основном речь идет о сервере, который отправил вам файл с html-текстом в нем (и, возможно, с прикрепленными заголовками). В результате в браузере есть HTML-файл, который можно обрабатывать.
  • CSR: процесс, при котором уже загруженный HTML-файл на клиенте (браузере) анализируется (выполняет файлы CSS, JavaScript, запросы изображений, шрифтов и т. д.), и в результате браузер может изменять DOM (изначально загруженный HTML-содержимым). На этот раз в результате пользователь действительно может увидеть страницу в браузере.

Основные варианты использования

Итак, нет выбора между выполнением только SSR или просто CSR, вы всегда будете делать и то, и другое, последовательно.

Ваша страница может быть легкой на стороне сервера (просто базовая структура html) и тяжелой на стороне клиента (выполняется много javascript), она может быть тяжелой на стороне сервера (много контента уже включено в html. файл, когда он создается сервером) и легкий на стороне клиента (только базовое поведение) или, возможно, тяжелый с обеих сторон.

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

Дело в том, что старая веб-парадигма «тонкого клиента» заменяется «толстым клиентом» благодаря эволюции движка браузера, обусловленной развитием javascript как языка.

Для стартапов хорошо, что сегодня у пользователей есть «целый компьютер» (это сотовый телефон), чтобы они могли более эффективно взаимодействовать друг с другом и избегать потребления ресурсов на стороне сервера.

Статический SSR против динамического SSR

Еще одно важное соображение - решить, хотите ли вы, чтобы HTML-файлы уже были сгенерированы (статический рендеринг), или вам нужно сначала обработать запрос, а затем создать (соответственно) HTML-файл на лету.

Я знаю, что это может показаться странным, но в большинстве случаев вы можете использовать статический или динамический SSR, позвольте мне объяснить это на примере.

Стратегия 1. Статическая страница профиля SSR в Facebook:

  • Понятно, что пользователь A и пользователь B будут выглядеть совершенно по-разному страницы профиля, так как же это возможно со статическим SSR?
  • Ответ - с облегченным SSR. Таким образом, вы не включаете много данных в HTML, только некоторая базовая структура, стили и javascript выполнят всю «тяжелую работу»: подключится к серверу, запросит данные для этого пользователя, а затем преобразует облегченный DOM в полностью обработанная страница профиля.
  • Но как сервер узнает, кто вошел в систему? Для этого вам понадобится cookie в клиенте (Not expired, Secure и HttpOnly), который будет отправлен на сервер вместе с запросом.
  • Затем сервер может прочитать файл cookie и отправить необходимые данные или перенаправить пользователя на страницу входа.
  • Примечание. Бывший сервер может быть не тем сервером, на котором вы запросили html-файл, мы назовем его «ApiServer» (подробнее об этом чуть позже).

Стратегия 2. Страница профиля Facebook с динамическим SSR:

  • В этом случае вместо этого мы можем сгенерировать html-файл со всем содержимым, специфичным для пользователя, запрашивающего страницу.
  • Во-первых, нам нужно знать, кто является пользователем и аутентифицирован ли он (для этого подходит тот же файл cookie из Стратегии 1), затем сделать запрос в базу данных для получения данных этого пользователя и, наконец, сгенерировать пользовательский HTML-код для отправки клиент.
  • Примечание. Этот сервер действует как ApiServer.

Итак, как решить? Вот компромиссы каждой стратегии

Статический SSR

  • Лучшая производительность: серверу не нужно создавать файлы (они уже есть)
  • CDN / Caching / Gzip: благодаря этому вы можете сжимать и кэшировать файл рядом с вашими пользователями, чтобы снизить задержку при сетевом вызове.
  • Требуется «тяжеловесная» CSR: поскольку HTML-файл будет довольно простым, клиент будет отвечать за выборку и рендеринг данных.
  • Требуется для управления процессом генерации html-файла: вы можете просто написать html-файл вручную, но вы, скорее всего, закончите с каким-то диспетчером процессов (например, gulp), который может вызывать некоторый процесс для генерации html. Это процесс только для разработчиков, вы можете сделать это на своем компьютере до развертывания.
  • Вам по-прежнему необходимо реализовать ApiServer, потому что верно, что вы можете обслуживать файлы html, css и js как статические файлы, но данные json, вероятно, всегда будут динамическими и зависимыми от пользователя.

Динамическое SSR

  • Не лучшая производительность: серверу необходимо генерировать ответ на каждый запрос, поэтому производительность может быть хорошей, но не лучшей.
  • Кеширование можно сделать, но это сложнее.
  • Вам не нужен процесс сборки для hmtl-файлов (вы создаете html-ответ на лету).
  • Вам не нужно внедрять отдельный сервер для обработки требований к данным («ApiServer»).
  • Ваша клиентская сторона может быть легкой (но, возможно, она будет тяжелой по другим причинам).

Теперь поговорим о рендеринге на стороне клиента.

Отрисовка на стороне клиента

Если мы хотим быть очень «каноническими» в отношении определений, рендеринг на стороне клиента - фактически единственный рендеринг, который происходит «на глазах у пользователя».

На изображении:

  • SSR (HTML) - это «инструкции» для браузера. Так что это не для людей, если вы не разработчик 😎
  • DOM (объектная модель документа) - это то, что скрывается за кулисами, когда браузер выполняет HTML. Но, опять же, это не для людей. Это представление о том, что происходит в браузере, и некоторые полезные API-интерфейсы для добавления поведения на страницу, предоставления хранилища и т. Д.
  • Веб-страница (фактическое отображение) - это то, что пользователи видят и с чем взаимодействуют. На изображении домашняя страница Google.

Итак, весь рендеринг можно рассматривать как процесс из 4 шагов:

  1. Вы нажимаете на ссылку, и браузеру требуется URL-адрес в Интернете.
  2. Сервер отвечает (благодаря DNS, который может его найти) файлом hmtl
  3. Боузер выполняет html-файл и запускает API-интерфейс DOM, который может понадобиться странице в ближайшем будущем. В результате пользователь теперь может видеть «что-то» на странице. Javascript еще не работает, но приближается ...
  4. Файлы javascript выполняются и теперь полностью контролируют содержимое страницы. Как результат:
  • Страницу SSR можно полностью изменить (скорее всего, она будет «расширена»)
  • JS может взаимодействовать с API DOM для плавного и постепенного внесения изменений на страницу.
  • Пользователь видит и чувствует отзывчивую страницу с событиями, происходящими после его щелчков и жестов.

NAQ: нечасто задаваемые вопросы

1. Когда прекращается процесс КСО?

= ›Когда пользователь нажимает ссылку на странице =› Указывает браузеру потребовать новый URL-адрес = ›При этом начинается новый цикл SSR-CSR.

2. Каждое изменение местоположения браузера запускает полный цикл рендеринга?

К счастью, нет.

Если вы знаете, что для новой страницы не потребуется загружать дополнительный javascript или что-то, что оправдывает запуск нового цикла, не делайте этого (используйте window.history.replaceState api). В противном случае используйте window.location.replace.

3. Заметил ли пользователь переход между SSR и CSR?

К сожалению, возможно.

Это действительно плохая практика - визуализировать что-то пользователю, исходящему с сервера, а затем иметь белую страницу в течение 3 секунд, а затем, наконец, иметь потрясающую страницу перед его глазами.

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

4. Нужна ли мне структура для SSR?

К счастью, нет.

Я использую React (на самом деле Preact), потому что он хорошо вписывается в мою ментальную схему мышления. Также с помощью React я могу преобразовать код javascript в строки html на сервере (SSR) и преобразовать страницу из состояния 1 в состояние 2 (на стороне клиента), не беспокоясь о согласовании или некотором императивном коде, который касается DOM.

Но! Моя текущая стратегия состоит в том, чтобы не делать тяжелый рендер на сервере и давать клиенту больше возможностей. Итак, содержимое моих html-файлов невелико и может быть создано без использования какой-либо структуры.

Но решать вам ...

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

Привет из Чили !! 🇨🇱