Разработка фронтенда ИТ-продукта: какой подход выбрать исходя из задач бизнеса

Сразу оговоримся, что в этой статье не рассматриваются варианты использования конструкторов сайтов вроде Tilda или Webflow. Мы работаем с заказчиками, запросы которых эти инструменты покрыть не в состоянии. Поэтому речь пойдет о разработке более сложных ИТ-продуктов: highload проектов, личных кабинетов в B2B и автоматизации бизнеса.  

Подход к разработке фронтенда в продукте – уже давно не прихоть разработчика, а инструмент для решения бизнес-задачи и разработки современных веб приложений. Расскажем простыми словами, почему это так, как выбор подхода зависит от назначения продукта, и приведем примеры.

Личные кабинеты, онлайн-сервисы, веб-приложения: клиентский рендеринг, рендеринг интерфейса 

Поговорим о приложениях, в которые пользователь заходит через логин: личный кабинет, внутренняя корпоративная система, CRM, ERP. Сюда же – интернет-банк, веб-интерфейс почты, личный кабинет на Озоне или Госуслугах, лента и переписка в соцсетях. Пользователь в таких приложениях видит данные, актуальные только для него. А индексация поисковиками для этих данных не нужна, поэтому используется метод клиентского рендеринга.  

Среди наших проектов, основанных на клиентском рендеринге, например, разработка личного кабинета пользователя для ЖК «Ньютон», система «Цессионарий».

Клиентский рендеринг (client side rendering) или SPA (Single Page Application) – метод, при котором браузер загружает основную структуру страницы и код приложения один раз и генерирует HTML код страницы в самом браузере на устройстве пользователя.

Далее при взаимодействии c пользователем браузер обращается в один или несколько API за дополнительными данными и динамически обновляет HTML без необходимости полной перезагрузки страницы. В результате, когда пользователь решит перейти в другой модуль, браузер откроет его практически мгновенно.

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

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

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

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

Отдельно отметим Progressive web apps (PWA): набор технологий, позволяющий максимально приблизить веб-приложения к привычным мобильным приложениям. Такой подход актуален сейчас, когда приложения регулярного удаляются из App Store и Google Play, а ограничить установку PWA-приложения не может никто.

PWA позволяет добавить ярлык приложения на рабочий стол телефона, работать без интернета, получать push-уведомления. Подход полезен также в случаях, когда делать отдельные мобильные приложения для iOS и Android в дополнение к веб-сервису слишком накладно или сложно. 

С клиентским рендерингом одна проблема — он не годится для проектов, требующих SEO-оптимизации. Поисковики плохо индексируют страницы, которые рендерятся в браузере, поэтому для SEO стоит применять другую архитектуру фронтенда.

Контентные порталы, медиа, блоги: статическая генерация сайта

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

Чтобы поисковики лучше индексировали сайт, HTML разметка для каждой его страницы должна отдаваться с сервера. Быстрота загрузки, как и качественное наполнение веб-страницы, влияет на ее позицию в выдаче поисковика. Поэтому важно, чтобы сайт загружался быстро – и на сервере, и в браузере. Этим целям отвечает статическая генерация.

Статическая генерация сайта (static site generation или SSG) – подход, при котором HTML код страниц генерируется один раз в момент публикации и сохраняется на сервере. Изменения в этой публикации не появляются (либо появляются очень редко), поэтому генерация «статическая». Дальше сервер будет моментально отдавать HTML код готовой страницы пользователям и поисковикам, гарантируя быструю загрузку страницы.

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

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

Headless CMS: конструктор и API для контента

Портал, предназначенный для публикации большого количества индексируемого контента, с использованием статической генерации – это хорошо. Однако контент нужно редактировать и хранить. Для этого мы используем Headless CMS. Например, Strapi.

Отличие Headless CMS от предыдущего поколения CMS вроде Битрикс или WordPress в том, что они не генерируют HTML‑код страниц сами, а просто предоставляют контент через API в структурированном виде.

Один и тот же контент из Headless CMS таким образом можно переиспользовать под различные каналы. Например, на сайте, в мобильном приложении или в email-рассылке.

Другой плюс – проекты на Headless CMS может делать фронтенд- разработчик целиком. В нашей команде фронтенд разработчики сами настраивают структуру контента в Headless CMS и интегрируются с ней — этому достаточно легко научиться. Не нужно дополнительно привлекать, например, PHP бекенд-разработчика, как при разработке на Битрикс или WordPress. 

Динамические интернет-магазины и пользовательский контент: серверный рендеринг

Контент, который часто публикуется и обновляется на портале, тоже может требовать индексации и непрерывного поддержания актуальности. Например, так происходит при разработке систем автоматизации бизнеса в онлайн-магазинах, где часто меняются цены, актуальные позиции или скидки (привет, Озон!). Другой пример – сайты, где в основе пользовательский контент — форумы и площадки с объявлениями, типа hh.ru или Авито. 

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

Серверный рендеринг (server side rendering / SSR) – подход, в котором страница генерируется на сервере при каждом запросе от пользователя.

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

Из этого вытекает потребность в более опытной и дорогой команде разработки.

Гибридные подходы

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

Самый частый и простой случай: догрузить в браузере динамических или персонализированных данных на статически сгенерированную страницу.

Так, на сайте нашего проекта для Crystal Palace FC большинство контента генерируется статически. При этом отдельные блоки рендерятся в браузере. Это, например, индивидуальные для пользователя блоки  или очень динамические сегменты. 

Другой пример – использовать статическую генерацию и клиентский рендеринг для различных разделов сайта. 

На одном из наших фронтендерских проектов – Seller Drive – портале для поставщиков Emex DWC, стартовая страница портала – индексируемая и общедоступная, поэтому реализована на статическом рендеринге. А вот личный кабинет, который становится доступен пользователю после аутентификации, мы построили уже на базе клиентского рендеринга. 

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

Что подойдет моему проекту

Чтобы выбрать самый эффективный подход для   создания веб приложения, портала, сервиса или личного кабинета для бизнеса, стоит на этапе переговоров с подрядчиком быть максимально честным. Как на приеме у доктора. И здесь главное для клиента приходить с запросом не в виде решения («Разработайте мне новый сайт»), а в виде описания своей боли («Мой старый сайт совсем не приносит денег, помогите»).

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