Что такое ssr react
SSR: рендеринг ReactJS приложения на бекэнде используя PHP
Перед нами стояла задача реализовать конструктор сайтов. На фронте всем управляет React-приложение, которое на основе действий пользователя, формирует JSON с информацией о том, как построить HTML, и сохраняет его на PHP бэкенд. Вместо дублирования логики сборки HTML на бэкенде, мы решили переиспользовать JS-код. Очевидно, что это упросит поддержку, так как код будет меняться только в одном месте одним человеком. Тут нам на помощь приходит Server Side Rendering вместе с движком V8 и PHP-extension V8JS.
В этой статье мы расскажем, как мы использовали V8Js для нашей конкретной задачи, но варианты использования не ограничиваются только этим. Самым очевидным выглядит возможность использовать Server Side Rendering для реализации SEO-потребностей.
Настройка
Мы используем Symfony и Docker, поэтому первым делом необходимо инициализировать пустой проект и настроить окружение. Отметим основные моменты:
Использование
Для демонстрации V8 создадим простой скрипт рендеринга H1 и P с текстом assets/front.jsx:
Переходим на localhost:8088 (8088 указан в docker-compose.yml как порт nginx):
Нажимаем кнопку сохранить, при нажатии на наш роут отправляется JSON:
В ответ отдается идентификатор записи в БД:
Теперь, когда есть тестовые данные, можно попробовать V8 в действии. Для этого необходимо будет набросать React скрипт, который будет формировать из переданных пропсов Dom компоненты. Положим его рядом с другими assets и назовем ssr.js:
Для того, чтобы сформировать из сформированного DOM дерева строку, воспользуемся компонентом ReactDomServer (https://unpkg.com/browse/react-dom@16.13.0/umd/react-dom-server.browser.production.min.js). Напишем роут с получением готового HTML:
Как видно, все было отрисовано именно так, как нам нужно.
Заключение
В заключении хочется сказать, что Server Side Rendering оказывается не таким уж сложным и может быть очень полезным. Единственное что стоит здесь добавить — рендер может занимать достаточно долгое время, и сюда лучше добавить очередь — RabbitMQ или Gearman.
React Server-Side Rendering (SSR) — руководство новичка
В этом уроке мы поговорим о серверном рендеринге (SSR), его преимуществах и подводных камнях. Затем мы создадим мини React проект и express сервер (Node.js), чтобы продемонстрировать, как можно достичь SSR.
Почти каждый второй сайт на данный момент является одностраничным приложением (SPA). Я уверен вы знаете, что такое одностраничное приложение. Такие фреймворки как Angular, React, Vue, Svelte и т.д. находятся на подъеме из-за их способности быстро и эффективно разрабатывать SPA. Они идеально подходят не только для быстрого прототипирования, но и для разработки сложных веб-приложений (если всё сделано правильно).
До недавнего времени для большинства сайтов HTML генерировался на сервере и отправлялся вместе с ответом, чтобы браузер мог визуализировать его на экране. Всякий раз, когда пользователь нажимал на ссылку для доступа к новой странице, мы отправляли серверу новый запрос на генерацию нового HTML для этой страницы. Нет ничего плохого в этом подходе, кроме времени загрузки и опыта пользователя.
Пользователю приходилось ждать несколько секунд, пока сервер получит запрос, соберет данные, составит HTML и вернет ответ. Так как это было полностраничной загрузкой, браузер должен был ждать все ресурсы, такие как JavaScript, CSS, и другие файлы, чтобы загрузить их снова (если только они не кешируются должным образом). Это было огромным неудобством для пользователя.
В настоящее время большинство веб-приложений запрашивают у сервера только данные. Вся генерация HTML осуществляется на стороне клиента (браузер). Всякий раз, когда пользователь нажимает на ссылку, вместо отправки нового запроса на сервер для получения HTML этой страницы, мы создаем HTML на стороне клиента, монтируя новые компоненты (строительные блоки веб-приложений), и запрашиваем у сервера только те данные, которые нужны для наполнения этого HTML.
Таким образом, мы предотвращаем полную перезагрузку страницы и значительно улучшаем время загрузки страницы. Мы программно изменяем URL в браузере с помощью History API, что не приводит к обновлению браузера. Так как обновление страницы никогда не происходит, мы запрашиваем только начальный HTML, который включает в себя JavaScript, CSS и другие средства для всего приложения.
В приведенном выше HTML,
Давайте поговорим о преимуществах и подводных камнях SPA.
= Преимущества
SPA дают опыт взаимодействия похожий на нативные приложения. Так как весь HTML приложения генерируется на стороне клиента, загрузка страницы происходит очень быстро.
Так как все ресурсы приложения, такие как JavaScript и CSS файлы, загружаются только один раз и никогда не запрашиваются снова после загрузки приложения, мы сильно экономим на пропускной способности сервера.
После начальной загрузки приложения мы запрашиваем у сервера только данные размером в несколько килобайт (по запросу). Таким образом, SPA идеально подходят для использования в условиях плохой сети.
Всё приложение может быть кешировано на клиенте (устройстве) с помощью service worker. Таким образом, при следующем обращении пользователя к сайту, браузеру больше не нужно будет загружать HTML и ресурсы. Когда пользовательское устройство не подключено к интернету, вместо отображения сообщения браузера по умолчанию «Не подключено к интернету!», мы можем отобразить пользовательский экран, который даст пользователю оффлайн-доступ.
Пользователи могут сохранить SPA как приложение на устройстве. Если вы заинтересованы в разработке мобильного приложения но не хотите тратить деньги на разработку нативных приложений (Android или iOS), SPA открывают возможность создать приложение похожее на нативное, используя ту же самую кодовую базу веб-сайта.
= Подводные камни
Так как SPA должен обслуживать все JavaScript и CSS файлы приложения вместе (обычно), эти файлы громоздки (несколько мегабайт). Следовательно, начальная загрузка приложения требует значительно больше времени, что означает, что пользователь будет видеть пустой экран в течение довольно долгого времени. При плохой сети это может быть серьезной проблемой. Однако, мы можем исправить это с помощью SSR.
В SPA, так как JavaScript управляет генерацией HTML на стороне клиента, SPA делают тяжелую работу на стороне клиента, которую раньше выполнял сервер. Поэтому SPA нуждаются в устройствах с хорошими возможностями в части процессора и батареи.
Так как исходный HTML, предоставляемый сервером (для всех страниц) не содержит HTML, специфичный для конкретного применения, поисковый движок видит веб-сайт как пустой, не имеющий никакого содержимого. Таким образом, ваш сайт может не попасть в топ поисковых результатов, несмотря на огромный трафик и релевантное содержание.
Из приведенного выше сравнения видно, что преимущества SPA превосходят их подводные камни. Наши устройства с каждым днем становятся все более производительными, а условия работы сети становятся все лучше и лучше. Поэтому нам больше не нужно беспокоиться об этом.
Тем не менее, каждый сайт хочет занять первое место в результатах поиска. Когда дело доходит до SPA, этого не очень легко достичь. Как мы уже говорили, когда поисковая система (crawler), такая как Google, видит наш веб-сайт, она видит HTML с пустым элементом
Причина, по которой я выделил «при первой загрузке», заключается в том, что этот подход не похож на традиционный рендеринг HTML на стороне сервера всего приложения. Здесь мы генерируем HTML на сервере только один раз для запрашиваемой страницы, так что поисковые системы видят правильный HTML, в то время как приложение будет вести себя в браузере точно так же.
Этот метод имеет еще одно дополнительное преимущество. Так как сервер будет возвращать правильный HTML для страницы, пользователь больше не будет видеть пустой экран, пока все ресурсы приложения не будут загружены. Нам для этого нужно будет настроить несколько параметров, но зато это будет очень удобно для пользователя.
Server-Side Rendering с нуля до профи
Проблема
Главной проблемой Single Page приложений является то, что сервер отдает клиенту пустую HTML страницу. Её формирование происходит только после того как весь JS будет скачан (это весь ваш код, библиотеки, фреймверк). Это в большинстве случаев более 2-х мегабайт размера + задержки на обработку кода.
Даже если Google-бот умеет выполнять JS, он получает контент только спустя некоторое время, критичное для ранжирования сайта. Google-бот попросту видит пустую страницу несколько секунд! Это плохо!
Google начинает выдавать красные карты если ваш сайт рендерится более 3-х секунд. First Contentful Paint, Time to Interactive — это метрики которые будут занижены при Single Page Application. Подробнее читайте здесь.
Также есть менее продвинутые поисковые системы, которые попросту не умеют работать с JS. В них Single Page Application не будут индексироваться.
На ранжирование сайта еще влияет множество факторов, часть из них мы разберем далее в этой статье.
Рендеринг
Существует несколько путей как решить проблему пустой странички при загрузке, рассмотрим несколько из них:
Static Site Generation (SSG). Сделать пререндер сайта перед тем как его загрузить на сервер. Очень простое и эффективное решение. Отлично подходит для простых веб страничек, без взаимодействия с backend API.
Server-Side Rendering (SSR). Рендерить контент в рантайме на сервере. При таком подходе мы сможем делать запросы backend API и отдавать HTML вместе с необходимым содержимым.
Server-Side Rendering (SSR)
Рассмотрим подробнее, как работает SSR:
Из вышеописанной работы SSR приложения мы можем выделить проблемы:
Это маленькая библиотека которая способна решить проблемы асинхронной обработки запросов к данным а также синхронизации состояния с сервера на клиент. Это не “очередной убийца Next.JS”, нет! Next.JS прекрасный фреймверк имеющий множество возможностей, но чтобы его использовать вам придется почти полностью переписать ваше приложение и следовать правилам Next.JS.
Посмотрим на примере, как просто перенести обычное SPA приложение на SSR.
К примеру, у нас есть простейшее приложение с асинхронной логикой.
Данный код рендерит список выполненных задач, используя сервис jsonplaceholder для эмуляции взаимодействия с API.
Сделаем данное приложение SSR!
Шаг 1. Установка зависимостей
Для установки iSSR нужно выполнить:
Для настройки базовой билд системы установим:
Один из неочевидных моментов разработки SSR приложений является то, что некоторые API и библиотеки могут работать на клиенте но не работать на сервере. Одним из таких API является fetch. Данный метод отсутствует в nodejs где будет выполняться серверная логика нашего приложения. Для того, чтобы у нас приложение работало одинаково установим пакет:
Для сервера будем использовать express, но это не важно, можно использовать любой другой фреймверк:
Добавим модуль для сериализации состояния приложения на сервере:
Шаг 2. Настройка webpack.config.js
Шаг 3. Модификация кода
Вынесем общую логику нашего приложения в отдельный файл App.jsx. Это нужно для того, чтобы в файлах client.jsx и server.jsx осталась только логика рендеринга, ничего больше. Таким образом весь код приложения у нас будет общий.
Мы поменяли стандартный render метод React на hydrate, который работает для SSR приложений.
В коде сервера обратите внимание, что мы должны расшаривать папку с собранным SPA приложением webpack:
app.use(express.static(‘public’));
Таким образом, полученный с сервера HTML будет работать далее как обычный SPA
Шаг 4. Обработка асинхронности
Мы разделили логику вынеся общую часть, подключили компилятор для клиент и сервер частей приложения. Теперь решим остальные проблемы связанные с асинхронными вызовами и состоянием.
Для обработки асинхронных операций их нужно обернуть в хук useSsrEffect из пакета @issr/core:
В server.jsx заменим стандартный renderToString на serverRender из пакета @issr/core:
Если запустить приложение сейчас, то ничего не произойдет! Мы не увидим результата выполнения асинхронной функции getTodos. Почему так происходит? Мы забыли синхронизировать состояние. Давайте исправим это.
В App.jsx заменим стандартный setState на useSsrState из пакета @issr/core:
Внесем изменения в client.jsx для синхронизации состояния переданного с сервера на клиент:
window.SSR_DATA — это объект, переданный с сервера с кешированнным состоянием, для синхронизации на клиенте.
Сделаем передачу состояние на сервере:
Обратите внимание, что функция serverRender передает не только HTML, но и состояние, которое прошло через useSsrState, мы его передаем на клиент, в качестве глобальной переменной SSR_DATA. На клиенте, данное состояние будет автоматически синхронизировано.
Шаг 5. Билд скрипты
Осталось добавить скрипты запуска в package.json:
Redux и прочие State Management библиотеки
iSSR отлично поддерживает разные state management библиотеки. В ходе работы над iSSR я заметил, что React State Management библиотеки делятся на 2 типа:
Мы не будем рассматривать этот пример так детально как предыдущий. Ознакомится с полным кодом можно по ссылке.
Redux Saga
*Для лучшего понимания происходящего, читайте предыдущую главу
Сервер запускает наше приложение через serverRender, код выполняется последовательно, выполняя все операции useSsrEffect.
Концептуально Redux работая с сагами не выполняет никаких асинхронных операций. Наша задача отправить action для старта асинхронной операции в слое Саг, отдельных от нашего react-flow. В примере по ссылке выше, в контейнере Redux мы выполняем
Это не асинхронная операция! Но iSSR понимает, что что то произошло в системе. iSSR будет идти по остальным React компонентам выполняя все useSsrEffect если таковые будут и по завершению iSSR вызовет каллбек:
Таким образом мы можем обрабатывать асинхронные операции не только на уровне с React но и на других уровнях, в данном случае мы в начале поставили на выполнение нужные нам саги, после чего в callback serverRender запустили и дождались их окончания.
Я подготовил много примеров использования iSSR, вы можете их найти по ссылке.
SSR трюки
На пути в разработке SSR приложений существуют множество проблем. Проблема асинхронных операций это только одна из них. Давайте посмотрим на другие распространенные проблемы.
HTML Meta Tags для SSR
Немаловажным аспектом в разработке SSR является использование правильных HTML meta tags. Они сообщают поисковому боту ключевую информацию на странице.
Для реализации данной задачи рекомендую использовать один из модулей:
React-Helmet-Async
React-Meta-Tags
Я подготовил несколько примеров:
React-Helmet-Async
React-Meta-Tags
Dynamic Imports
Чтобы снизить размер финального бандла приложения, принято приложение делить на части. Например dynamic imports webpack позволяет автоматически разбить приложение. Мы можем вынести отдельные страницы в чанки или блоки. При SSR мы должны уметь обрабатывать данные фрагменты приложения как одно целое. Для этого рекомендую использовать замечательный модуль @loadable
Dummies
Некоторые компоненты или фрагменты страницы можно не рендерить на сервере. Например, если у вас есть пост и комментарии, не целесообразно обрабатывать обе асинхронные операции. Данные поста более приоритетны чем комментарии к нему, именно эти данные формируют SEO нагрузку вашего приложения. По этому мы можем исключать не важные части при помощи проверок типа:
localStorage, хранение данных
NodeJS не поддерживает localStorage. Для хранения сессионных данных мы используем cookie вместо localStorage. Файлы cookie отправляются автоматически по каждому запросу. Файлы cookie имеют ограничения, например:
React Server Components
React Server Components возможно будет хорошим дополнением для SSR. Его идеей является снижение нагрузки на Bundle за счет выполнения компонент на сервере и выдачи готового JSON React дерева. Нечто подобное мы видели в Next.JS. Читайте подробнее по ссылке
Роутинг
React Router из коробки поддерживает SSR. Отличие в том, что на server используется StaticRouter с переданным текущим URL, а на клиенте Router определяет URL автоматически при помощи location API. Пример
Debugging
Дебаг на сервере может выполняться также как и любой дебаг node.js приложений через inpsect.
Для этого нужно добавить в webpack.config для nodejs приложения:
devtool: ‘source-map’
А в настройки NodemonPlugin:
Также, для улучшения работы с source map можно добавить модуль
В nodeArgs опций NodemonPlugin добавить:
‘—require=«source-map-support/register»’
Пример
Next.JS
Если вы создаете приложение с нуля, рекомендую обратить внимание на данный фреймверк. Это самое популярное решение на данный момент для создания с нуля приложений с поддержкой SSR. Из плюсов можно выделить то, что все идет из коробки (билд система, роутер). Из минусов — необходимо переписывать существующее приложение, использовать подходы Next.JS.
SEO это не только SSR!
Критерии Google бота для SEO оптимизации включают множество метрик. Рендер данных, получение первого байта и т.д. это лишь часть метрик! При SEO оптимизации приложения необходимо минимизировать вес картинок, бандла, грамотно использовать HTML теги и HTML мета теги и прочее.
Для проверки вашего сайта при SEO оптимизации можно воспользоваться:
Server Side Rendering для React App на Express.js
На написание этой статьи меня сподвигло отсутствие какого-либо более-менее полного мануала, как же сделать Server Side Rendering для React приложения.
Когда я столкнулся с этой проблемой, у меня было 2 варианта это сделать, либо Next.js фреймворк, либо используя Express.js.
На инвестигейт Next.js было потрачено около 100 часов, чтоб завести его для нашей готовой крупной OTT платформы, но проблем было настолько много, что мы от него отказались (по этому поводу напишу статью еще), остался выбор за малым, Express.js, про который я и хочу рассказать.
Полный код демо-примера, рассматриваемого в статье, тут.
Начнем с первоначальной задачи и то, что у нас было.
Мы имели на тот момент:
Из документации реакта, мы можем узнать, что для SSR можно использовать renderToString() и hydrate() методы, но что с ними делать дальше?
renderToString — используется для генерации HTML на сервере нашего приложения.
hydrate — используется для универсального рендера на клиенте и на сервере.
Загрузка данных
Для загрузки данных на стороне сервера используем библиотеку redux-connect, которая позволяет загружать необходимые данные, до вызова первого рендера, то, что нам и надо. Для этого используется hoc asyncConnect. На серверной части он загружает данные, а при роутинге он работает как componentDidMount.
Нам надо создать redux store на стороне сервера. Все как обычно, только создаем в файле server.js.
Также на стороне сервера с помощью метода loadOnServer из redux-connect дожидаемся предзагрузки данных.
С помощью renderToString мы получаем Html нашего приложения с данными.
Данные, которые мы засетили в стор, можно достать с помощью getState() и добавить через тег ‘, «); return res.send(data); >); >); store.close(); >); >);
В компонент ReduxAsyncConnect передаются 2 пропса:
первый — это наши роуты, второй хелперы (вспомогательные функции), которые мы хотим, чтоб были доступны по всему приложения, некий аналог context.
Для серверного роутинга надо использовать StaticRouter.
Для добавления seo meta тэгов используется бибилиотека helmet. В компоненте каждой страницы есть описание с тегами.
Для того, чтоб с сервера приходили сразу тэги тоже, используется
Роутинг надо было переписать на массив объектов, это выглядит так.
В зависимости от url, который приходит на сервер, react router отдавал нужную страницу с данными.
Как выглядит клиент?
Вот главный файл клиентской части. В него можно добавлять аналитику для поисковиков и код, который должен выполняться для каждой страницы на стороне клиента.
Для роутинга используется ConnectedRouter из connected-react-router/immutable.
Для серверного рендеринга мы не можем использовать react-router-dom и сообстветственно описать наш роутинг через Switch:
Вместо этого, как уже говорилось, у нас есть массив с описанными роутами, и для того, чтоб нам их добавить в приложение, нужно использовать react-router-config:
Загрузка каритнок, стилей и шрифтов на сервере
Для стилей использовался isomorphic-style-loader, так как обычный slyle-loader не работает в вебпаке с target: “node”;
Он добавляет все стили в DOM, тем самым с сервера приходит уже готовая, красивая страница. Можно сохранять в отдельный файл стили, тем самым они смогут кешироваться браузером.
Для отображения картинок и загрузки шрифтов на сервере был использован webpack loader base64-inline-loader.
Он был включен для изображений и всех типов шрифтов, которые мы использовали. В результате мы получали с сервера base64 код, который отображал страницу с шрифтами и изображениями без последующей загрузки.
Для клиентского билда использовался обычный url-loader и file-loader.
Да, это увеличило размер загружаемой страницы, но не сильно было заметно для пользователя по скорости загрузки.
Динамический импорт на сервере
В React.js для динамического импорта и отображения лоадера используются React.lazy и React.suspense, но они не работают для SSR.
Мы использовали react-loadable, который выполняет то же самое.
На клиенте этот код отображает лоадер, на сервере, для того, чтоб модули загрузились, нужно добавить следующий код:
Loadable.preloadAll() — возвращает промис, который говорит, что модули подгружены.
Все основные моменты решены.
Я сделал мини демо с использованием всего, что было описано в статье.
Создание SSR веб приложения на React и NodeJS с нуля до деплоя (статья 1)
Содержание
Предисловие
Добрейшего времени суток %HABRUSER% и проходящим мимо, в первую очередь я очень рад что ты открыл эту статью, без шуток 🙂
Данная серия публикаций посвящена созданию сервиса runwith суть которого вы сможете почитать ниже. Это мой первый независимый проект, поэтому буду очень рад вашим комментариям и конструктивной критике касаемо стиля написания статьи и кода в целом, надеюсь тебе будет полезно и интересно, приятного чтения!
Идея сервиса
Было 2 мотивации для создания приложения. Спорим что почти каждый из нас когда то говорил себе:
Уже завтра начну заниматься спортом (С)
и забивал огромный гвоздь в эту ветку развития, если вы не забивали, то огромный F таким людям, но лично я не такой, мне нужна компания для таких занятий, так меньше шанса забить да и в целом вместе же веселей 🙂 это первая мотивация, найти компанию для совместного занятия бегом.
Мотивация #2 была технического характера, давно хотелось разобраться в SSR на ReactJS ( если быть точней в создании гибридного приложения SSR & SPA ).
Посидев немного в среде этих мотиваций родилась идея создания сервиса, в котором всяк сюда входящий найдет компаньона для бега в real-time.
Так как проект некоммерческий (а значит времени и средств на его реализацию не слишком много) решил что стоит начать с MVP и допиливать уже в продакшне функциональность.
На момент создания MVP приложение должно уметь
Находить напарника (или напарников до 10 участников) для бега в реальном времени (то есть здесь и сейчас).
Давать возможность для поиска напарника(ов) по выбранному району, а так же выбирать начальную и конечную точку забега.
Уметь хорошо проиндексировать себя в поисковике.
Делать серверный роутинг
Иметь 2 страницы (Главная и новости для ознакомления с тем, что поменялось на проекте для пользователя)
Так как я фронтенд реактус разрабус, стек будет соответствовать:
ReactJS (Последних версий, будет писать на хуках)
Typescript (Да это увеличит время разработки из-за дополнительной разработки типов, но приложение может сильно расширяться, поэтому типизация нам пригодится во избежания 1 + «1» = 11 и других подобных приколов слабой типизации JS )
Sass (Был выбор между LESS и PCSS, PCSS собирается быстрей из-за того что плагины ставятся разработчиком и нет ничего лишнего, но sass как то родней как по мне скорость компиляции не столь критична на данных момент)
react-router-dom (Роутинг на клиенте)
express (Для упрощения серверной разработки)
Socket.IO (Наше все, создание комнат, real-time поиск, отображение комнат на клиенте)
react-router (Роутинг на сервере)
Webpack (Собственно собирает наш проект)
cross-env (Нам нужны будут системные переменные, для того чтобы определять как собирать проект для разработки или прода и другие)
nodemon (Перезапускает наш сервер при пересборке, чтобы ручками не делать каждый раз при каждом чихе)
Так же другие плагины которые есть в package.json нашего проекта. От статью к статье плагины могут добавляться | удаляться.
Почему не хочу использовать NextJS
NextJS это фреймворк, а любой фреймворк навязывает много правил в разработке и проблемы при каких то кастомных решений (это неплохо но на данный момент противоречит моей 2 мотивации), мне хотелось бы чтобы проект был максимально гибкий, а так же разобраться в работе под капотом гибридного приложения.
Архитектура приложения
Так как статья получается очень объемной, в этой части опишу только основную структуру нашего приложения, в следующей начну с детальной реализации клиентской и серверной части.
Не устал читать структуру клиентской стороны?) Я вот очень устал ее писать, однако давай перейдем к архитектуре сервера:
Тут все максимально просто 🙂
Теперь вебпак конфиги (именно конфиг(И), потому что мы должны собрать как клиент, так и сервер)
Заключение и источники
В данной статье постарался рассказать о мотивации создания проекта, о стеке, отличие SSR от SPA и что такое гибридное приложение, а так же архитектуре его директорий. Ссылочка на гит для ознакомления прилагается.
Если у вас остались какие то вопросы или допустил какие то неточности или статью можно как то улучшить, пожалуйста пишите, буду рад почитать ваши комментарии 🙂