Доброго времени суток.
Сегодня поговорим о проектах, которые содержат в себе большое количество статического контента. К таким проектам могут относится, как новостные сайты, лендинги, так и магазины. Ожидаю закономерного вопроса: “Где в интернет-магазине статический контент?”, предлагаю разобраться вместе.
Возьмем рандомный интернет-магазин, посмотрим на любую карточку товара и заметим, что здесь не так уж много динамической информации. На примере ниже видно, что из динамики: цена, время доставки и, собственно, всё.
В большой карточке товара ровно тоже самое.
Как мы видим, данный тип сайтов не сильно интерактивен, хотя требует множество людских и машино-ресурсов. Также не стоит забывать, что для некоторых сайтов требуется SEO, а значит - дополнительные расходы. Со временем потребуется оптимизация расходов, которой может стать использование JAM stack.
Посмотрим, что требуется для работы подобного сайта:
админка (CMS). В ней заполняется вся информация о товарах, регионах, и т.д. Её придется создать самому или взять готовый шаблон;
БД, в которой будут храниться данные;
бек, для связи БД с клиентом;
web клиент (потребуется написать самому);
SSR для поисковых ботов.
Это не полный перечень того, что потребуется с технической точки зрения. Как минимум, добавьте сюда хороший сервер, а лучше облако, в котором будет крутиться инфраструктура. Не забудьте и накладные расходы (справедливо только по отношению к SPA).
Есть ли альтернатива?
Для начала разберемся какие типы сайтов существуют.
Single Page Application (SPA) — одностраничное веб-приложение, которое загружается на одну HTML-страницу. Благодаря динамическому обновлению с помощью JavaScript, во время использования не нужно перезагружать или подгружать дополнительные страницы. На практике это означает, что пользователь видит в браузере весь основной контент, а при прокрутке или переходах на другие страницы, вместо полной перезагрузки, нужные элементы просто подгружаются.
В процессе работы пользователю может показаться, что он запустил не веб-сайт, а десктопное приложение, так как оно мгновенно реагирует на все его действия, без задержек и «подвисаний».
Такого эффекта удается добиться с помощью продвинутых фреймворков JavaScript: Angular, React, Ember, Meteor, Knockout.
Плюсы
высокая скорость — все ресурсы загружаются за одну сессию, а во время действий на странице данные просто меняются, что очень экономит время;
гибкость и отзывчивость пользовательского интерфейса — за счет того, что веб-страница всего одна, проще построить насыщенный интерфейс, хранить сведения о сеансе, управлять состояниями представлений и анимацией;
упрощенная разработка — код можно начинать писать с файла file://URL, не используя сервер. Не нужен отдельный код для рендера страницы на стороне сервера;
кэширование данных — приложение отправляет всего один запрос, собирает данные, а после этого может функционировать в offline-режиме.
Минусы
seo оптимизация требует решений в виде серверного рендеринга — контент загружается при помощи технологии AJAX, которая подразумевает динамическое изменение содержания страницы, а для оптимизации важна устойчивость;
нагрузка на браузер — из-за того, что клиентские фреймворки тяжелые, они довольно долго загружаются;
необходима поддержка JavaScript — без JS нельзя полноценно пользоваться полным функционалом приложения;
утечка памяти в Java Script — из-за плохой защиты, SPA больше подвержена действиям злоумышленников и утечке памяти.
Multi Page Application (MPA) — многостраничные приложения, которые работают по традиционной схеме. Это означает, что при каждом незначительном изменении данных или загрузке новой информации страница обновляется. Такие приложения тяжелее, чем одностраничные, поэтому их использование целесообразно только в тех случаях, когда нужно отобразить большое количество контента.
Плюсы
простая SEO оптимизация — можно оптимизировать каждую из страниц приложения под нужные ключевые запросы;
привычность для пользователей — за счет простого интерфейса и классической навигации.
Минусы
Тесная связь между бекендом и фронтендом, поэтому их не получится развивать параллельно;
сложная разработка — требуют использования фреймворков, как на стороне клиента, так и на стороне сервера, что увеличивает сроки и бюджет разработки.
Progressive Web Application (PWA) — прогрессивные приложения, взаимодействуют с пользователем, как десктопные приложение. Они могут устанавливаться на главный экран смартфона, отправлять push-уведомления и работать в офлайн-режиме. Ярким представителем такого рода приложения являются Google Docs.
Плюсы
кроссплатформенность — могут работать сразу с несколькими операционными системами;
высокая скорость работы — возможность запуска и отображения данных в оффлайн-режиме с моментальной загрузкой;
высокая скорость установки;
быстрая разработка — для создания PWA, не нужен отдельный сайт, достаточно изменить уже существующий.
Минусы
Не все браузеры поддерживают основные функции таких приложений (например, Firefox и Edge).
Как мы видим третий тип сайта очень специфичный, поэтому не будем брать его в расчет. Значит из альтернатив нас интересует SPA и MPA.
Всем известно, что если кому-то из разработчиков не подходит уже существующее решение, то он изобретает свой “велосипед”. Так получилось и в этот раз: так создали JAM Stack.
Что это такое JAM Stack?
Ну начнем с очевидного и невероятного — это аббревиатура. Как она расшифровывается?
«J» (JavaScript) — это основной язык программирования, который используют веб-приложения для работы в браузере.
«A» (API) — это способ запроса данных из других сервисов.
«М» (разметка) — это код разметки (HTML и CSS), предоставляющий браузерам инструкции по форматированию страниц.
Термин был придуман Матиасом Бильманом, соучредителем Netlify. Согласно официальному сайту, JAMstack – это современная архитектура (архитектурный паттерн) веб-разработки, основанная на клиентском JavaScript, повторно используемых API и предварительно созданной разметке.
Как он работает?
Для того чтобы понять как работает JAM Stack для начала разберём, как работает обычный сайт:
Пользователь запрашивает страницу.
Хостинг обрабатывает его запрос и начинает выполнять цепочку операций (иногда очень длинную) между базой данных, сервером и т.д (Backend).
По завершении этой работы пользователь получает в ответ HTML-страницу.
Все обновления сайта загружаются на сервер через FTP/SSH.
Существует отдельная сущность — база данных, которую необходимо поддерживать и обслуживать. При этом она является неотъемлемой частью сайта.
Для обновления контента необходимо использовать админку (CMS).
JAM Stack работает иначе, точнее гораздо проще.
Пользователь запрашивает страницу.
HTML-файл уже лежит готовенький и только и ждёт этого запроса. Ответ следует моментально.
Для обновления контента используется Git или Headless CMS.
Сайт автоматически пересобирается с помощью генератора статических сайтов или самостоятельно настроенной системы сборки.
Рассмотрим ещё детальнее:
Как видно из сравнения на чертеже: традиционная схема в разы больше и более громоздкая, чем схема JAM stack. Посмотрим на составные части JAM stak:
Headless CMS — принципиально иная система управления нежели классическая CMS. Headless CMS по сути реализует паттерн микросервестной архитектуры на беке. Как правило, она отвечает только за универсальное содержимое, которое может использоваться на любых платформах. Логика Headless CMS такова, что к бэкенд при необходимости можно приставлять разный фронт. Это позволяет использовать один бекенд для управления сайтом (или сайтами) и мобильным приложением, а также автоматизировать распространение контента по всем доступным площадкам и устройствам. В результате минимизируются ресурсы, затрачиваемые на веб-разработку. А управление разными платформами осуществляется централизованно из одного интерфейса, что удобно. При этом содержимое гибко настраивается для каждого отдельного канала.
Шаблонизатор — отвечает за внешний вид, от него зависит выбор ssg.
Static Site Generators (SSG) — это генерация всех HTML страниц приложения в момент сборки.
Система публикации сайта — по факту хостинг, на котором лежит ваш проект (страницы).
Разобрались с частями системы, теперь рассмотрим последовательность действий для реализации проекта:
Заполняем необходимую информацию с помощью Headless CMS. Рекомендую начинать именно с этого, так как на этом этапе проще работать с заготовкой.
Создаем шаблон отображения при помощи любого шаблонизатора: будь-то angular, react, vue или что-то другое.
Генерируем страницы при помощи SSG. Выбор SSG зависит от того на каком шаблонизаторе вы остановились ранее.
Загружаем всё на хостинг и наслаждаемся результатами своей работы.
Что он дает?
Скорость — в совокупности с обработанным статичным HTML и сетью CDN, Jamstack сайты невероятно быстрые.
Добавьте методы предварительной обработки, встроенные в SSG и Jamstack может показаться практически мгновенным. Google, Amazon и eBay продемонстрировали влияние малых улучшений скорости сайта на конверсию и вовлечение пользователей. Добавьте к этому подтверждение Google, что скорость страницы является фактором ранжирования для поиска (скорость страницы важна для хорошего SEO).
Пока вы не переборщите с большим количеством JavaScript, ваш сайт на Jamstack будет работать быстро. И не только ваш сайт будет быстрым: использование Jamstack ускорит вашу скорость выхода на рынок. Очень важно быть проворным и готовым реагировать на изменения рынка. Если ваша устаревшая платформа веб-сайта замедляет работу, то внедрение Jamstack, безусловно, поможет решить эту проблему.
Стабильность — управление и поддержка устаревших приложений занимает много времени, особенно когда первоначальные разработчики давно ушли или вы унаследовали чужой код (поверьте, мы знаем, что это такое).
Вы когда-нибудь добавляли что-то новое на ваш сайт, случайно ломая нечто в другом месте? В основе подхода Jamstack лежит то, что ваши конечные пользователи получают доступ к статическому HTML. Этот статический HTML может быть доставлен через CDN, без сложных серверных приложений и баз данных, что обеспечивает очень стабильную архитектуру. Конечно, нам иногда придется полагаться на сторонние API-интерфейсы для управления динамическими функциями, но при правильной настройке, из-за простоя API-интерфейса, ваш сайт не перестанет работать.
Расширяемость — в то время как другие преимущества в этом списке могут быть достигнуты в традиционной архитектуре согласованными усилиями (и затратами), очень трудно конкурировать с архитектурой Jamstack, когда дело доходит до масштабируемости. Из-за отсутствия серверов веб-приложений, серверов баз данных и прямой доставки через сети CDN и периферийных вычислений, стоимость масштабирования веб-сайта или приложения Jamstack значительно меньше по сравнению с веб-сайтом или приложением на основе базы данных (даже при хорошем управлении кэшем).
Безопасность — компонент веб-сайтов и приложений, управляемых базой данных, требует подключения к веб-серверу и базе данных для доступа к данным, нужных для создания веб-страницы, запрошенной конечным пользователем. Эта связь является слабым местом, когда речь идет о безопасности. Сайт Jamstack представляет собой статический HTML. Нет сервера, нет базы данных, нет слабых мест (если вы не делаете что-то очень глупое с вашим JavaScript).
В чем подвох?
Высокий порог входа — не смотря на то, что в целом подход прост, требуются хорошие знания JS. Они пригодятся, когда будете выбирать нужный шаблонизатор, настраивать систему сборки, разбираться как работает Headless CMS и как собрать всё воедино.
Не подходит для сильно интерактивных приложений — просто из-за особенности подхода.
Скорость сборки — из-за значительного количества страниц их генерация может занять до 20 минут времени, а это плохо сказывается на общей скорости опубликования. В момент генерации также повышается нагрузка на базу данных, что может еще больше замедлить процессы опубликования.
Желательно использование CDN — для достижения максимальной эффективности приходиться использовать CDN, но это требует времени, пока все файлы заменяются, кэш успеет сброситься.
Как видите есть преимущества и недостатки, поэтому перед тем как браться за работу, требуется всё взвесить и понять критичные моменты для вашего проекта.
Что-то полезное
При изучение данной темы я столкнулся с тем, что вся информация размазана тонким слоем по разным ресурсам. Временами встречалась какая-то конкретная реализация, но JAM stack это архитектурный паттерн и рассматривать какую-то конкретную связку, мягко говоря, не очень полезно. Это связано с тем, что, как минимум, она (связка) может вам не подойти так как у вас используется другой шаблонизатор.
Сокращу ваше время общения с google и ниже дам ссылки на полезные ресурсы и библиотеки, которые могут пригодиться в работе.
jamstack.org — официальный сайт комьюнити. На нем вы сможете найти документацию, выбрать Headless CMS (на момент написания статьи их было около 100), подобрать SSG (на момент написания статьи их было около 350) или понять в целом workflows.
netlify.com — один из лучших CDN хостингов, который предоставляет возможность быстро и удобно публиковать проекты
Плагины для e-commerce
Плагины для форм
Плагины поиска
Плагины для комментариев
швейцарский нож — тут вы найдете почти все, что вам может понадобиться при разработке статического сайта. Если вам это будет полезно, поставьте автору лайк: если бы не он, я бы о многом вообще вряд ли узнал.
Выводы
JAM stack не святой грааль, но в его силах помочь в определенных обстоятельствах. Он может сделать ваш проект быстрее и удобнее (в разумных пределах). Включайте голову, и это принесет плоды.
Подход финансово выгоден как переходной вариант. По сути можно обойтись одними фронт-разработчиками и сэкономить на хостинге. Проектам, как правило, требуется место, а не вычислительные мощности. Место же, в текущих реалиях, стоит в разы меньше, что серьезно экономит бюджет. За счет скорости проект будет выше в выдачи в поисковой выдаче. Ещё данный подход хорош для проектов с малым количеством интерактивности.
P.S.
Данная статья была написана, с целью ознакомления с подходом. Я с радостью отвечу на возникшие вопросы и выслушаю Ваше мнение о данном подходе (в комментариях).
