Создаём блог. История разработки веб-приложений

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

История сайтов

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

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

С появлением PHP и ASP технология Server-side Rendering (SSR) становится доминирующей среди создателей веб-сайтов. Отныне все страницы (исключая полностью статические) генерируются на серверной стороне, HTML-формы по-прежнему являются основным способом взаимодействия с пользователем на стороне браузера.

Принципиально новый подход к созданию веб-приложений приносит сначала добавление в язык HTML тэга iframe, а в дальнейшем объекта XMLHttpRequest. Теперь создатели сайтов получают возможность динамически асинхронно подгружать данные с сервера и выполнять на текущей открытой странице Javascript-код (который в свою очередь может генерироваться сервером в зависимости от действий пользователя).

Начинают появляться сайты, состоящие из небольшого числа страниц, всё содержимое которых динамически формируется на клиентской стороне с помощью Javascript. Такие сайты называют Single-page Application или SPA, а технологию их создания — Client-side Rendering (CSR).

Эти сайты выглядят как полноценные приложения, однако время загрузки первой страницы может быть достаточно велико, к тому же, как и в случае SSR, необходимы постоянные динамические запросы к серверу за данными для отображения и рендеринга страницы. С ростом интернет-трафика в мире и соответствующим ростом нагрузки на серверы, обрабатывающие запросы таких сайтов, вновь популярной стала технология статических страниц, Static Site Generation или сокращённо SSG. В этот раз для генерации страниц используются современные шаблонизаторы и фреймворки, ориентированные на генерацию статических сайтов, такие как Gatsby, Next, Hugo, Jekyll.

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

Сравнение

Все технологии скорее дополняют друг друга, чем заменяют. Более того, все они могут сосуществовать даже в рамках одного веб-приложения (или даже в рамках одной страницы): например, статически сгенерированная страница новостного сайта может использовать серверный API для реализации кнопки «Нравится», а сайт, созданный на технологии SSR содержать полностью статические страницы с редком меняющимся содержимым.

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

SSR (Server-side Rendering)

Преимущества:

SEO-friendly — поисковые роботы могут легко обойти сайт, сделанный на SSR, так как каждая страница полноценна и самодостаточна, высокая скорость загрузки основного контента (LCP);
низкая нагрузка на браузер — клиент получает уже готовую страницу, которая мало чем отличается от статически сгенерированной;
не требует запросов к серверу после загрузки — сервер может не предоставлять никакого API для отображения страниц, каждая из них получает все необходимые для ёё формирования данные уже на этапе генерации страницы (по умолчанию это не делает такой подход более безопасным, чем, например, CSR, так как все равно требует от разработчика валидировать пользовательские данные, на основании которых генерируется страница).

Недостатки:

высокая нагрузка на серверы — каждая загрузка страницы требует от сервера сгенерировать под конкретный запрос клиента новую версию страницы;
относительно медленная загрузка страницы — чтобы клиент начал отображать страницу, она должна быть сгенерирована сервером, как правило полность, ещё до передачи клиенту первых байтов информации (некоторые фреймворки предлагают частичное решение этой проблемы);
меньшая эффективность кэширования — в целом в приложении получается меньше статических данных, которые можно разместить, используя технологии хостинга статического содержимого, например, CDN;
увеличение трафика — содержимое каждой страницы сайта доставляется до клиента при каждом обновлении страницы или переходе на другую страницу сайта.

Когда использовать? Сайты с активно меняющимся содержимым — интернет-магазины, новостные и информационные сайты, форумы.

CSR (Client-side Rendering)

Преимущества:

после полной загрузки приложение работает как обычное десктопное приложение, для перерисовки интерфейса не требуется забирать с сервера код новой страницы — по сути это единственный способ рендеринга, который позволяет создавать полноценные аналоги десктопных приложений (прогрессивные веб-приложения);
низкая нагрузка на серверы — веб-приложение может использовать уже существующий публичный API или для него может быть реализован достаточно простой CRUD-подобный API, например, на Serverless-решениях (многие облачные провайдеры предлагают бесплатные тарифы для размещения такого кода, к примеру, в Яндекс.Облаке можно рассчитывать на 1 млн. не тарифицируемых вызовов функций в месяц);
возможность смены UI-фреймворка, чёткое разделение границ серверной и клиентской части — так как код сервера более не занимается рендерингом страниц, а отдаёт данные в общеизвестном формате (например, JSON), у такого приложения значительно проще заменить клиентскую часть или даже сделать несколько реализаций приложения, работающих с одним сервером.

Недостатки:

долгая загрузка первой страницы — при старте приложения обычно показывается пустая страница с надписью «Идет загрузка»;
большой размер приложения — так как большая часть логики находится на клиенте, а на сервере реализован достаточно простой API, то размер необходимого кода, который браузер должен будет скачать, может быть существенным, при этом обновлении версии приложения будет приводить к скачиванию кода ещё раз;
даже простые действия пользователя могут приводить к множественным запросам к серверу — можно записать это и в плюсы и в минусы, с одной стороны это увеличивает трафик и может выливаться в увеличение стоимости хостинга приложения (особенно, если вы платите не только за объем переданных данных, но и за количество запросов к серверу, например, в случае использования Serverless-решений), с другой стороны, такие запросы можно запускать параллельно и асинхронно, что повышает «отзывчивость» интерфейса в целом;
SEO-unfriendly — поисковые роботы не всегда могут получить корректное содержимое страницы, так как это требует выполнения Javascript-кода с дальнейшей отрисовкой содержимого страницы;
меньшая защищенность от Cross-site Scripting — по своей природе SPA полагается на исполнение произвольного кода на клиентской стороне;
меньшая устойчивость к утечкам памяти — так как приложение постоянно запущено во вкладке браузера и перезагрузка страницы не требуется, ошибки в коде, связанные с утечками памяти, становятся более критичными и приводят к замедлению работы приложения.

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

SSG (Static Site Generation)

Преимущества:

максимально высокая скорость доставки страницы до клиента — можно использовать практически любые способы оптимизации доставки таких страниц от стриминга для ускорения доставки первых байт до CDN для минимизации расстояния от клиента до ближайшего сервера;
простота организации кэширования — страница по одному и тому же адресу остаётся неизменной продолжительное время;
лёгкость масштабирования — при росте аудитории проекта и нагрузки, достаточно просто добавить дополнительные ресурсы для выдачи содержимого страниц, не нужно думать о масштабировании базы данных или серверной части приложения; такие сайты можно легко и бесплатно разместить, например, на сайтах хостинга открытого кода типа Github;
безопасность — поверхность атаки таких сайтов ограничена веб-сервером, отдающим статические страницы;
SEO-friendly — как и в случае SSR поисковые роботы могут легко обойти такой сайт, так как каждая страница полностью статична.

Недостатки:

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

Когда использовать? Сайты с редко меняющимся содержимым — документация, блоги, сайты-визитки.

Выводы

Нетрудно догадаться, что вряд ли имеет большой смысл делать блог целиком как Single-Page Application, однако выбор между SSG и SSR не так очевиден. С одной стороны содержимое блога меняется нечасто, с другой — динамические элементы (например, комментарии) являются важным содержимым и должны учитываться, например, при обработке страниц поисковыми роботами. Тем не менее основу блога и его базовые функции необходимо уметь выкладывать как полностью статические HTML-страницы, чтобы была возможность размещать его полностью бесплатно и не зависеть от дорогостоящих серверных ресурсов.

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

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

Все части серии на одной странице