Главная » Статьи » Как Smashing Magazine управляет контентом: переход с WordPress на JAMstack

Как Smashing Magazine управляет контентом: переход с WordPress на JAMstack

Как Smashing Magazine управляет контентом: переход с WordPress на JAMstack

От автора: WordPress очень популярен. Так почему бы сайту на WordPress не рассмотреть возможность перехода на JAMstack? В этом посте мы рассмотрим, как выглядит миграция с WordPress, используя, в качестве примера, сам Smashing Magazine! Мы поговорим о плюсах и минусах, о вещах, которые мы хотели бы знать заранее, и о том, что нас удивило.

Каждый раз, когда разработчики говорят о WordPress, они называют разную долю рынка. «20% всех сайтов работает на WordPress!», «40% всех сайтов работает на WordPress! » Каким бы ни был процент, суть та же: с точки зрения принятия WordPress очень популярен.

Так почему же при таком широком принятии не подумать о переходе на JAMstack? В этой серии статей, состоящей из двух частей, мы рассмотрим, как выглядит фактическая миграция WordPress, на примере конкретного сайта, который вы сейчас и читаете.

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

Давайте начнем!

Почему?

В 2015 году соучредитель Netlify Матиас Билманн и основатель Smashing Виталий Фридман пообщались в магазине. Когда архитектура JAMstack начала делать первые успехи, Smashing стал больше интересоваться этим. Виталий и Маркус (бывший управляющий директор Smashing) спросили Мэтта, что произойдет, если Smashing перейдет с традиционного WordPress / LAMPstack на архитектуру JAMstack.

В качестве эксперимента Мэтт удалил весь HTML из Smashing и разместил его на Netlify, доставляя контент статически из CDN. Результаты были впечатляющими — статическая версия в стала среднем более чем в шесть раз быстрее!

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

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

Итак, сцена была подготовлена. Smashing Magazine перешел на JAMstack — в частности, на Netlify в качестве платформы. За 10 лет работы Smashing превратился из небольшого онлайн-ресурса в огромный WordPress блог, где продаются такие вещи, как книги, билеты на конференции и семинары.

Сайт состоял из несколько частей:

Блог на WordPress

Доска вакансий на Rails

Магазин на Shopify

Еще одна CMS для сайта конференции

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

Надежность

Smashing регулярно достигает того, о чем мечтают другие платформы: статьи широко распространяются огромным сообществом. Однако, когда Smashing достиг опереженного порога, у него регулярно возникали проблемы с перебоями в работе. Чтобы смягчить это, интенсивно были введены в стек плагины WordPress, но они все еще изо всех сил пытались сохранить хорошие показатели времени безотказной работы.

Переход на Netlify позволил команде Smashing избежать ошибок при подключении к базе данных и не беспокоиться о простоях, даже когда статья получала огромный объем трафика. Почему? Потому что при обслуживании без сервера готовый контент не нужно создавать и доставлять — он уже существует и готов к просмотру. На месте ничего не запрашивается, кроме всей статической страницы.

Обслуживание через CDN также позволило Smashing вздохнуть немного свободнее в плане безопасности. wp-login.php долгое время был источником дыр в безопасности и векторов атак. Предварительно собранный контент не может быть доступен таким же образом, и дыры в безопасности не столь критичны.

Инвалидация кэша

Smashing по кругу использовал различные плагины кеширования WordPress – с переменным успехом и множеством проблем. Виталий Фридман из Smashing вспоминает:

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

Переход на Netlify позволил команде Smashing увидеть мгновенную ивалидацию кэша, а также обслуживать кэшированный контент без дополнительных затрат.

При развертывании сайта файлы HTML размещаются в CDN Netlify. Он оптимизирован под высокую частоту обращений к кэшу и быстрое время до первого байта, а также позволяет мгновенно аннулировать все HTML-файлы, которые были изменены. Netlify также снимает отпечатки всех ссылок на ресурсы, такие как CSS-файлы, изображения, шрифты или JS-файлы, и выполняет доставку Smashing с заголовками кэширования, которые кешируют их навсегда. Снятие отпечатков гарантирует, что они уникальны, и что если вы обновите версию ресурса, будет предоставлена его более новая версия.

Рабочий процесс

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

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

Часть миграции WordPress оказалась самой сложной и деликатной. Netlify попытался экспортировать данные из экспортера WP, но обнаружил, что контент содержал встраивания, которые необходимо было сохранять, или которые время от времени изменялись с помощью плагинов. Чтобы сохранить паритет с тем, что было на сайте, была написана серия скраперов, разделенных для статей, материалов, комментариев и главной страницы.

После этого они были загружены в новый репозиторий на GitHub, а вместо них использовалась Netlify CMS. Уникальность Netlify CMS в том, что она легкая и интегрирует редакторы контента в рабочий процесс Git — это означает, что она будет в буквальном смысле извлекать и обслуживать файлы markdown из репозитория git вместо базы данных. Кроме того, Netlify CMS не зависит от платформы и работает (почти) со всеми генераторами статических сайтов и сайтами, хранящимися в GitHub.

В то время в Smashing в качестве внештатного front-end разработчика над редизайном работала Сара Суэйдан. Она создала библиотеку компонентов для построения интерфейсной архитектуры и отметила, насколько проще стал процесс, потому что она работала непосредственно в git, даже при работе с CMS.

«Все, что я поместила в репозиторий, напрямую применяется к библиотеке шаблонов, что означает, что вам не нужно поддерживать два разных набора компонентов … этот тип непрерывности был великолепен! Все, что мне нужно сделать, это написать HTML, CSS и JavaScript и нажать на репо, и все работает как по волшебству. Рабочий процесс был фантастическим».

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

Вот почему в следующем руководстве, мы рассмотрим модель, при которой вы можете воспользоваться преимуществами панели инструментов WordPress для авторов контента, но WordPress используется через API, реализуя Git-ориентированный рабочий процесс для разработки, что упрощает разработку и поддержку.

Выбор фреймворка

В первоначальном прототипе, который создал Мэтт Билманн, он написал все на минимальном Preact в паре с Hugo, так как его основным приоритетом была производительность. Он просто использовал свойство, чтобы сохранить малый размер. Когда он передал проект для поддержки разработчику Smashing, Илье Пухальскому, он обнаружил, что в Preact отсутствуют некоторые функции, которые им нужны, чтобы подключаться к экосистеме React. В итоге преимущества Redux и других библиотек перевесили соображения малого размера.

Оглядываясь сейчас назад, Мэтт говорит, что использовал бы Vue, который в то время не был достаточно распространен (клянусь, я не побуждала его сказать это). Я задала очевидный вопрос: почему не Svelte? Так как люди, ориентированные на производительность, стремятся к использованию этой библиотеки. Он упомянул, что у Svelte пока нет экосистемы, которой обладает Vue.

Когда Мэтт размышляет над тем, будет ли он по-прежнему использовать Hugo, он говорит, что ему нравится Hugo, но очень трудно найти для этого проекта некоторые плагины – для создание баннерной рекламы и тому подобного. Эти вещи недостаточно охвачены Hugo, и ему нужно было вводить собственные скрипты. Эти скрипты, как правило, замедляют процесс сборки. Тем не менее, мы по-прежнему используем Hugo для собственного сайта на netlify.com и он нам нравится — это чрезвычайно специфично для потребностей сайта Smashing.

Если бы он мог сделать это заново, он мог бы выбрать либо Eleventy, который обладает богатыми возможностями в плане создания плагинов и других расширяемых скриптов. Или, если бы он использовал Vue, Nuxt предложил бы ему хорошие возможности создания плагинов, обеспечивая рендеринг на стороне сервера, маршрутизацию и статическую генерацию.

Создание больших сайтов

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

Но это преимущество имеет место только в том случае, если сайт создан заранее, и этот процесс может занять много времени. В то время как более традиционные сайты будут создавать страницы по запросу, мы буквально создаем каждую страницу заранее на тот случай, если она понадобится пользователю. Это делает представление супер быстрым! Но теперь значительное время уходит на разработку и публикации — создание каждой страницы может занять время.

Это не такая серьезная проблема для небольших сайтов, но в масштабе Smashing Magazine нам нужно было уделить этому внимание, чтобы люди могли поддерживать высокую производительность при активной ежедневной разработке контента.
Netlify создал большой каталог /production-articles, в котором было много тысяч статей, которые они уже размещали. Затем был создан отдельный рабочий каталог content/articles, в который можно было помещать статьи, которые в данный момент создаются и редактируются.

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

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

API с открытым исходным кодом

Вначале мы упоминали, что, помимо прочего, Smashing интересовала миграция существующего решения электронной коммерции, обработка комментариев вне WordPress и добавление функционала для аутентификации. Все эти функции были реализованы с помощью решений с открытым исходным кодом, которые поддерживает Netlify, разбив их на API без сохранения состояния:

GoTell API — инструмент сборки для обработки большого количества комментариев.

GoCommerce — небольшой API на основе Go для сайтов электронной коммерции, который обрабатывает заказы и платежи.

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

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

Заключение

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

Маркус Сейферт, бывший генеральный директор Smashing Magazine, отметил: «Время первой загрузки намного быстрее, чем раньше… раньше нам приходилось ждать, пока HTML-файл будет обслужен, 800 мс, а теперь 80 мс».

Этот процесс был успешным, и, как в случае любого инженерного проекта, в ходе работы были извлечены ценные уроки. В следующей статье этой серии мы рассмотрим руководство и демонстрацию того, что мы бы порекомендовали, учитывая полученные нами знания. Если вы хотите модернизировать разработку WordPress и воспользоваться преимуществами производительности и безопасности JAMstack, читайте следующую часть!

Автор: Sarah Drasner

Источник: https://www.smashingmagazine.com

Редакция: Команда webformyself.