Зачем нужен серверный рендеринг

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

Для начала мы снова вспомним схему работы классических сайтов. Сервер генерирует контент и отдаёт его пользователю, JS добавляет интерактив.

Важным здесь является как раз интерактив, например банальная кнопка "подписаться" которая будет иметь два состояния:

  1. "подписаться" - для состояние когда подписка ещё не оформлена
  2. "отписаться" - в после того как подписка была оформлена

Итак, до того как придумали AJAX и прочие прелести процесс происходил следующим образом: пользователь нажимал на ссылку (или кнопку) отправлялся запрос и затем сервер возвращал пользователю новую страницу с учётом обновлённого состояние подписки.

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

Во первых сервер по прежнему должен предоставлять разные кнопки в зависимости от состояния подписки, во вторых клиент так же должен уметь менять состояние кнопки после того как подписка была обновлена с помощью AJAX.

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

Проблемы дублирования логики

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

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

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

Серверный рендеринг

Итак, мы подошли к тому, что было бы неплохо оставить логику отображения только в одном месте, оставить её только на сервере мы не можем, потому что лишимся какого либо интерактива на клиенте, и у нас остаётся вариант перенести всю логику отображения на клиента.

Здесь нас поджидают проблемы индексации, но на текущий момент поисковые движки умеют индексировать сайты с клиентским рендерингом, если он достаточно быстрый. Но совсем не хочется рисковать в этом вопросе, и был придумал серверный рендеринг.

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

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