- Published on
Создаём блог. Проектируем платформу для ведения блога
В предыдущей части мы рассмотрели основные варианты разработки современных веб-приложений и реализации их самой главной функции — формирования HTML-содержимого. В этой части попробуем нарисовать архитектуру нашего приложения и более детально разобрать необходимые для его создания инструменты и технологии.
Как устроено современное веб-приложение?
Большинство современных веб-приложений работает по клиент-серверному принципу: клиентская часть используется для отображения пользователю информации (как правило, это HTML-страница в браузере), серверная — отвечает за бизнес-логику приложения, формирует динамические страницы сайта, взаимодействует с базой данных, исполняет периодические фоновые задачи (например, рассылку писем или уведомлений в мессенджеры).
В зависимости от назначения приложения, нагрузки на него, объёма хранимых и обрабатываемых данных архитектура приложения может смещаться от преимущественно серверной до преимущественно клиентской. Если для простого сайта-визитки или блога хватит только веб-сервера для хостинга однажды сгенерированных статических HTML-файлов, то для создания онлайн-игры или мессенджера уже потребуются довольно внушительные вычислительные ресурсы. Так или иначе, любое веб-приложение будет состоять из трёх крупных компонентов.
- Фронтенд — часть, отвечающая за отображение. Здесь может, например, находиться код шаблонизатора, генерирующего HTML-страницы из подготовленных бэкендом данных, или исполняющийся на клиентском браузере Javascript (который, впрочем, тоже может быть сгенерирован сервером фронтенда). Нередко во фронтенде может присутствовать и бизнес-логика приложения, тесно связанная с его визуальной частью.
- Бэкенд — часть, отвечающая за обработку данных и взаимодействие между компонентом, отвечающим за отображение, — фронтендом и хранилищем данных — как правило, традиционной базой данных. Бэкенд отвечает за большую часть бизнес-логики приложения, позволяет приложению быть более динамичным, выполнять скрытые от пользовательских глаз манипуляции с данными, фоновые задачи.
- База данных — часть, отвечающая за хранение данных и доступ к ним. Обычно это SQL- или NoSQL-база данных, в которой бэкенд хранит доменную модель приложения. В некоторых случаях своеобразной базой данных может выступить и простой репозиторий с кодом или распределенная файловая система или объектное хранилище типа S3.
Современные веб-приложения обычно построены на архитектуре BFF (Backend for Frontend). Что это такое и почему это считается стандартом в разработке веб-приложений хорошо написано в статье Архитектура современных корпоративных Node.js-приложений. Такой подход в частности позволяет получить более чистую архитектуру и разделить слои бизнес-логики и представления. При этом совсем необязательно, чтобы каждый из архитектурных компонентов имел физическое представление в реальном мире. Например, в качестве базы данных для статического сайта можно использовать репозиторий с кодом или файловое хранилище, а роль бэкенда для нашего персонального блога вполне может взять на себя компонент внутри фронтенда на Node.js.
Изначально и на протяжении всего проекта мы будем стараться минимизировать число выделенные в отдельные сущности компонентов системы, пытаясь не потерять в чистоте и гибкости построенной архитектуры. На первых порах наш блог будет полностью статическим сайтом — это самый простой и дешёвый способ разместить сайт в интернете. С ростом возможностей блога нам всё равно придётся использовать динамические, требующие серверной части компоненты. Эти компоненты будут включаться отдельными настройками, так что каждый сможет выбрать необходимую функциональность и требуемые для неё ресурсы. Равно как и в случае масштабирования по нагрузке или объёму данных: выбранная архитектура не должна приводить к необходимости приобретать дорогой сервер для хостинга персонального блога с небольшой нагрузкой, при этом нужно иметь возможность легко масштабировать сайт, если он стал популярным ресурсом.
Из чего состоит разработка и поддержка сайта?
Помимо непосредственно написания кода нам также потребуется разместить где-то базовую инфраструктуру для разработки и соединить ее с инфраструктурой, где будет размещено наше приложение. Для старта будет достаточно какого-нибудь открытого репозитория кода. Почему открытого? Во-первых, чтобы можно было делиться (в том числе здесь) этим кодом, во-вторых, такие сайты, в отличие от закрытых репозиториев, как правило бесплатны, а мы хотим максимально сэкономить на разработке и последующей эксплуатации нашего сайта.
С выбором репозитория тесно связана задача организации тестирования и CI/CD. Так как сайт должен будет работать в том числе в отсутствие серверной части, нам нужно будет решить вопрос с наполнением блога содержимым и последующими сборкой и выкладкой сгенерированных страниц на веб-сервер. К счастью, современные открытые репозитории уже экипированы средствами сборки проектов, основанных на популярных Javascript-фреймворках, типа Next.js или Vue, и поддерживают интеграции с различными платформами хостинга статических сайтов, например, GitHub Pages или Cloudflare Pages.
Альтернативным решением может быть использование облачных провайдеров, таких как Яндекс.Облако, AWS или GCP. Все они содержат какой-то небольшой бесплатный объём услуг, позволяющий организовать процесс сборки и хостинга небольшого сайта, а само содержимое сайта разместить в S3. Главный плюс такого решения — возможность расширить потенциал сайта за счёт разнообразных сервисов, предлагаемых этими провайдерами. Например, можно поселить в них динамическую часть сайта в виде serverless-контейнера или serverless-функции, а для базы данных выбрать бессерверную базу данных типа Serverless YDB или Amazon Aurora Serverless. Существенный недостаток — непредсказуемость потребления и, как следствие, уязвимость к Denial of Wallet Attack.
Ещё один интересный вариант хостинга и сайта, и его инфраструктуры сборки — платформы хостинга, ориентированные на разработчиков приложений, такие как Vercel, Netlify, Heroku и другие. Такие решения часто строят компании, разрабатывающие веб-фреймворки. Их основной плюс — возможность очень быстро и без усилий развернуть всю необходимую инфраструктуру, сборку, деплой, DNS-хостинг, а также отличная интеграция с фреймворками, используемыми для разработки веб-приложений. Минусы — довольно высокая цена при достижении бесплатных лимитов и сложность кастомизации таких решений и переноса их на другие платформы, ограниченный выбор технологий.
Кроме всего вышеперечисленного нам также необходимо будет зарегистрировать доменное имя сайта и настроить всю необходимую для его работоспособности в связки с сайтом инфраструктуру, например, DNS, SSL-сертификат для домена, почту. В последующих частях мы более детально рассмотрим, как устроены эти вещи изнутри, и выберем оптимальные с точки зрения затрат и перспектив варианты. После того как сайт будет готов к размещению на нём страниц с полезным содержимым, мы поизучаем темы, связанные с поисковой оптимизацией (SEO), аналитикой и защитой сайта от DDoS-атак.
Наконец, важной частью процесса разработки являются инструменты, с помощью которых мы будем писать код, тестировать его и наполнять содержимым наш сайт: среда разработки, язык разметки и рисования диаграмм, инструменты проверки правописания, оптимизации изображений — всё это мы тоже рассмотрим в одной из статей этого цикла.
Финальный дизайн архитектуры приложения
Несмотря на то что наш блог будет развиваться итеративно и больше будет походить на типичный бардак стартап, мы всё же зафиксируем некоторые особенности его архитектуры уже сейчас.
На схеме я привёл один из возможных вариантов архитектуры нашего приложения. Она построена вокруг общего репозитория с кодом и содержимым сайта, на базе которого генерируется его статическая и динамическая части. Для хостинга сайта я использовал облачную платформу (это может быть Amazon AWS, GCP, Яндекс Облако или примерно любой другой современный облачный провайдер). Статическая часть впоследствии складывается в S3-бакет, а для динамической создаётся Serverless-функция, которая при необходимости также может работать с облачной базой данных. Для того чтобы динамическая часть стала доступной снаружи для внешних пользователей сайта, вызовы к ней осуществляет API Gateway, который принимает внешние HTTP-запросы. Управление SSL-сертификатами также возложено на облачную инфраструктуру, в составе которой, как правило, присутствует менеджер сертификатов.
С таким подходом нам не нужно думать о системе управления содержимым сайтом, её роль берёт на себя репозиторий с кодом. С одной стороны это может показаться не очень удобным, с другой — однажды попробовав Git, понимаешь, насколько это гибкий и универсальный инструмент: версионирование, совместная работа над статьями, возможность согласований и рецензирования перед публикацией — всё это становится доступным совершенно бесплатно, без единой строчки кода. А наличие вокруг репозиториев удобных систем CI/CD позволяет также устранить ручные действия при публикации статей.
Как уже говорилось выше, не все из компонентов на диаграмме могут использоваться в конкретном сайте. Позже мы более детально рассмотрим вопрос кастомизации нашего блога и сделаем возможность включать и выключать выбранные компоненты, а также использовать различные решения для разработки и хостинга сайта. Выбор в каждом конкретном случае будет зависеть от потребностей создателя сайта и оправданности применения той или иной технологии. Например, для сайта, основная аудитория которого располагается в России, может быть разумным использовать российский хостинг, а для международного проекта — Cloudflare CDN.
Выводы
Современная разработка веб-приложений и сайтов — не только и не столько про написание кода. Большая часть усилий, на самом деле, тратится на архитектурные и инфраструктурные моменты:
- как спроектировать сайт и его разработку так, чтобы было удобно его поддерживать и обновлять;
- как сэкономить на тестировании и хостинге;
- как удобно организовать управление содержимым сайта;
- как сделать сайт безопасным, надёжным и масштабируемым.
В следующей части выберем репозиторий для исходного кода и более детально поговорим об инфраструктуре разработки и деплоя нашего приложения.