DE{CODE}: Headless 101 для разработчиков WordPress

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

Слайды сессии

Полный текст стенограммы

ГРЕЙС ЭРИКСОН : Добро пожаловать в Headless 101 для разработчиков WordPress. Меня зовут Грейс Эриксон, и я являюсь помощником разработчиков здесь, в WP Engine. Ко мне присоединяется Стив из Haus. Сегодня мы собираемся дать вам краткое представление о том, что такое безголовый WordPress и как вы можете начать его использовать.

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

В традиционной архитектуре издатель создает и управляет контентом, таким как сообщения в блогах и страницы, внутри WordPress. Разработчик пишет код для управления внешним видом и функциями сайта, используя PHP и API тем WordPress. Затем WordPress генерирует HTML-страницу, которая отправляется посетителю.

В этой объединенной архитектуре CMS WordPress предоставляет издателям возможности управления контентом. И он также отвечает за предоставление HTML-страниц посетителям веб-сайта. Безголовая CMS использует развязанную архитектуру, в которой интерфейс и сервер управляются отдельно. В безголовой архитектуре издатель по-прежнему создает и управляет контентом в WordPress, как и в традиционной архитектуре WordPress.

Разработчик пишет код для управления внешним видом и функциями сайта на JavaScript, а также использует WPGraphQL или REST API для извлечения данных из WordPress. Фреймворк, такой как Faust.js, Next.js, Nuxt.js или SvelteKit, часто используется для поддержки этого внешнего приложения. Затем внешнее приложение JavaScript генерирует и обслуживает HTML-страницы, которые отправляются посетителю веб-сайта.

В отличие от традиционной архитектуры, WordPress больше не отвечает за создание HTML-страниц. Таким образом, взаимодействие по обмену контентом между серверной частью WordPress и внешним приложением JavaScript происходит через уровень API. Два варианта уровня API — это WordPress REST API или WPGraphQL.

REST API поставляется в комплекте с WordPress. Однако требуемый шаблон доступа к данным может быть медленным, поскольку REST требует, чтобы каждый ресурс имел собственную конечную точку. Например, для реконструкции полностью смоделированного поста потребуется несколько обходов. Если вы хотите получить содержимое, автора и категорию сообщения, вам потребуются три отдельных вызова API.

В отличие от этого, WPGraphQL позволяет нам запрашивать содержание поста, автора и категорию в одном запросе. По этой причине WPGraphQL является нашим предпочтительным уровнем API. WPGraphQL — это бесплатный плагин, который предоставляет расширяемую схему GraphQL и API для вашего сайта WordPress. WPGraphQL быстрее, чем REST API, потому что он получает точные данные, которые запрашиваются, и приводит к меньшему количеству функций, выполняемых за счет оптимизации запросов, меньшему количеству загрузки данных, более эффективной загрузке данных и включению нескольких ресурсов в один запрос.

Безголовая архитектура дает разработчикам свободу выбора из любого внешнего стека технологий, наиболее популярными из которых являются фреймворки JavaScript. Некоторые из самых популярных интерфейсных JavaScript-фреймворков включают React, Vue.js и Svelte. Новые фреймворки выпускаются постоянно, так что этот список далеко не полный.

Многие из этих фреймворков JavaScript используются в сочетании с метафреймворками, которые добавляют решения для таких вещей, как маршрутизация, рендеринг на стороне сервера и многое другое. React используется в сочетании с Next.js, Vue.js используется в сочетании с Nuxt.js, а Svelte используется в сочетании с SvelteKit. Gatsby — еще один популярный мета-фреймворк.

WP Engine разработал Faust.js, фреймворк JavaScript, построенный на основе React и Next.js. Faust был создан специально для поддержки безголовых веб-приложений WordPress. Он поддерживает аутентификацию и предварительный просмотр сообщений из коробки, предоставляет удобные встроенные хуки React для доступа к данным WordPress и многое другое.

Итак, мы поговорили о том, что означает безголовая архитектура WordPress и какие технологии вы будете использовать. Но давайте быстро коснемся того, почему вы даже выбрали бы безголового. WordPress сам по себе является тяжелой CMS и использует PHP, который не является быстрым языком. Безголовый WordPress использует приемные языки через JavaScript и загружает только необходимые файлы через вызовы API. Он намного легче, поэтому ваш сайт будет загружаться быстрее.

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

Теперь давайте покопаемся в коде настоящего безголового сайта. Я предварительно записал пошаговое руководство по новому безголовому сайту WordPress Atlas Blueprints. Новая функция Blueprints в Atlas предоставляет очень простой способ запустить полноценный безголовый сайт WordPress. Они поставляются со стартовым кодом, плагинами, моделями контента и структурой страницы, чтобы ускорить запуск вашего приложения.

Итак, давайте создадим новый сайт Blueprint, чтобы мы могли погрузиться в код. Изнутри приборной панели WP Engine мы перейдем к Atlas. Щелкните Создать приложение. Выберите «Начать с чертежа». И затем мы собираемся выбрать, какой план мы хотим использовать. Я собираюсь выбрать проект портфолио.

Затем вы подключите свою учетную запись WP Engine к своей учетной записи GitHub и клонируете этот план в новый репозиторий. Это займет пару секунд, чтобы построить. Наконец, вы просто выбираете имя только что созданного репозитория, ближайший к вам регион, а затем нажимаете «Создать приложение».

Теперь, если вы нажмете на URL-адрес Atlas, мы сможем увидеть, как выглядит наш безголовый сайт WordPress. Нас особенно интересует страница сообщений. Как видите, сайт загружает все самые последние сообщения на эту страницу нашего блога. И каждый пост также имеет свою индивидуальную страницу просмотра. Но откуда все эти данные?

Если мы вернемся к панели инструментов WP Engine, мы увидим кнопку для WP Admin. Это серверная часть нашего безголового сайта WordPress. Если я нажму «Сообщения», вы увидите тот же список, что и веб-приложение. Теперь мы можем открыть репозиторий GitHub, в который был клонирован наш Blueprint. И давайте клонируем это репо в нашу локальную среду.

Затем я собираюсь открыть этот репозиторий в Visual Studio Code, моем любимом редакторе кода. Перейдя в каталог проекта, файл страницы блога можно найти в SRC, pages, posts, Index.js. Этот проект создан с использованием React, Next.js, Faust.js и WPGraphQL. Если вы не знакомы с React или даже с JavaScript, поначалу это может показаться запутанным.

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

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

Наконец, мы добираемся до компонента поста, который принимает в качестве параметра список постов с разбивкой на страницы. Давайте посмотрим, что компонент post делает с этой информацией. Здесь он перебирает каждое сообщение, содержащееся в списке сообщений, которые он получил. Для каждого поста он отображает карточку на странице последнего поста. Первый состоит из компонента избранного изображения, обернутого ссылкой на страницу отдельного сообщения в блоге, заголовка заголовка сообщения и информационного компонента сообщения, состоящего из даты и автора сообщения.

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

Спасибо Blueprints за обработку установки Headless для нас. Было просто разбить то, что входит на страницу сообщения, чтобы получить данные из бэкэнда WordPress с помощью WPGraphQL и отобразить сообщения с помощью компонентов React. Спасибо за внимание. Вы можете найти меня в Твиттере @graceerixon.

Посетите сайт developer.wpengine.com, чтобы узнать больше о Headless WordPress. У нас есть учебник о том, как создать свой первый сайт Headless WordPress с нуля с помощью Faust.js, и прямо сейчас мы работаем над серией контента Headless 101. Вы можете получить все инструменты, которые предлагает Atlas, если зарегистрируете бесплатную учетную запись Sandbox. Теперь я передам это Стиву, чтобы он больше рассказал о том, почему Haus выбрала Headless WordPress для своего проекта leoburnett.com.

СТИВ СКАВО: Спасибо, Грейс. Привет, я Стив Скаво, технический директор Haus. Мы креативная технологическая студия и агентство из Лос-Анджелеса, Калифорния. Это выступление называется Headless 101 for WordPress Developers. И если честно, я не являюсь разработчиком WordPress по профессии, но я думаю, что это часть красоты безголовой архитектуры.

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

Так почему же без головы? Есть так много причин высокого уровня, о которых мы могли бы говорить, но я думаю, что такие разговоры о реальных производственных примерах и примерах из реального мира, когда это сияет, действительно полезны. И я хотел бы продемонстрировать проект, который мы сделали для Лео Бернетта с использованием безголового в безголовой архитектуре. Для контекста: Leo Burnett — легендарное рекламное агентство из Чикаго, но у них много офисов по всему миру. Так что у них много контента, много работы.

Старый сайт работал на одной теме WordPress. Это было действительно фрагментировано, немного медленно, не очень хорошо работало. Его было трудно обновлять, и он не совсем демонстрировал тот стиль и брендинг, которые хотел передать Лео Бернетт. Вот с чем мы начали работать с точки зрения дизайна. И мы выбрали безголовых, чтобы действительно модернизировать их стек.

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

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

Итак, одна из первоначальных проблем с headless заключается в том, что всегда приходится принимать множество решений, касающихся хостинга, развертывания и инфраструктуры, и это всегда было огромной проблемой. Таким образом, эти решения о стеке всегда оставались на усмотрение разработчика. И вы ищете, и вы придумываете, хорошо, какое стороннее приложение, может быть, CI / CD вам нужно использовать? Мы собираемся разместить это на AWS? Как мы это делаем? Какие услуги? И затем вы как бы реализуете такие потенциально-эти специальные решения вокруг этого потока.

Что ж, платформа Atlas и WordPress Engine Atlas действительно решает эту проблему. Вот где это вступает в игру. Мы выбрали Atlas по всем этим причинам, и у них есть эта управляемая сервисная инфраструктура. Они стандартизируют конвейер CI/CD. Вам действительно не нужно думать об этом.

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

А потом еще эта усталость от микросервисов и DevOps. Это просто тяжелая когнитивная нагрузка, связанная с тем, как много вы должны думать, поддерживать и осознавать это как разработчик и поддерживать его в рабочем состоянии. Это все вещи, которые платформа Atlas действительно убирает из ваших рук и решает с выгодой для себя.

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

Это позволяет нам выбирать стек, в котором мы хотим писать код. Для нас это Haus, Next.js и React. Next.js — это просто замечательный фреймворк с некоторыми действительно хорошими соглашениями о маршрутизации, производительности и архитектуре приложений. И мы также хотели внедрить систему дизайна, и не просто систему визуального дизайна, а кодифицированную систему дизайна. Это то, что делает наше приложение стабильным, проверенным и красивым.

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

Нам также нужно много творческого запаса. Когда вы посещаете leoburnett.com, вы можете увидеть красивые переходы между страницами. Есть — мы не привязаны к традиционному стеку WordPress в том, как должны отображаться вещи. WordPress больше не отвечает за рендеринг интерфейса.

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

Удобство администратора улучшилось, и я думаю, что мы оптимизировали его, потому что мы никогда не отходили от их старого знакомства. Там нет backend cutover. Мы перешли с WordPress на WordPress. Нам не нужно было экспортировать данные и писать сценарии, чтобы перейти на другую проприетарную систему. Так что знакомство огромное. Мы хотели сохранить такой поток для текущих администраторов leoburnett.com.

Принятие и документация — если вы проводите пять минут в Интернете, вы, вероятно, коснулись серверной части WordPress, и это просто невозможно переоценить. У Leo Burnett также есть много очень специфических элементов контента и настраиваемых полей. WordPress предлагает это и дает вам эту возможность, но мы смогли внедрить плагин Advanced Custom Fields, который является действительно хорошим соглашением по настройке пользовательского интерфейса администратора, чтобы сделать его действительно удобным и удобным. Так что это была победа в опыте администратора.

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

Они бесшовные. Они отзывчивы. Они просто чувствуют себя хорошо. И я думаю, мы хотели, чтобы Leo Burnett и все наши приложения чувствовали себя именно так. Возможность выбирать стек, который мы хотим, на внешнем интерфейсе, позволяет нам это делать.

Нативные приложения по своей природе отделены от внутренней инфраструктуры контента, как и наши веб-приложения. И это то, что Атлас продвигает. Это то, чему вообще способствует безголовая архитектура. Это также способствует производительности. Мы можем универсально отображать наш пользовательский интерфейс. Это означает, что начальная нагрузка находится на стороне сервера. И после этого за дело берется клиент.

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

Для Лео Бернетта, с точки зрения API контента, который мы выбрали для использования, мы настроили конечную точку GraphQL. Это означает, что возвращаются более скудные полезные нагрузки. Мы явно определяем именно тот контент, который нам нужен. После рендеринга на стороне сервера в рендеринг на стороне клиента меньше гидратации.

Это меньше кода, поступающего по сети, меньше откликов, меньше времени отклика. Это определенно победа, и я бы посоветовал, если вы собираетесь перейти к рабочему процессу Atlas или безголовому рабочему процессу, внимательно изучить использование API GraphQL, а не что-то вроде REST API.

И с точки зрения пользователя, они видят свежий, своевременный контент. Это процесс публикации, оптимизированный для предварительного просмотра контента. Он оптимизирован для быстрой загрузки контента на этапе подготовки и предварительного просмотра, а затем его продвижения в производство. Администраторы Leo Burnett очень довольны тем, как легко обновлять контент, и это делает пользователей счастливыми.

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

Когда разработчики вдохновлены, они используют оптимизированный набор инструментов. Это просто хорошо. Они счастливы. Они пишут лучший код.

Администраторы знают, что они создают контент в красивой экосистеме. Это быстро. Отправляется быстро. И пользователи видят этот обновленный контент и видят современный, красивый, хорошо функционирующий и оптимизированный внешний интерфейс.

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

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

Вы же не хотите создать красивый веб-сайт и взвалить на себя бремя. Мы в Haus очень гордимся тем, что не делаем этого. И я думаю, что замечательно в Atlas и Atlas как платформе то, что она решает эту проблему.

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

Потому что помните, мы не просто создаем веб-сайт. Мы создаем систему публикации контента, и это очень важно понять и признать с первого дня. И снова здесь в игру вступает Атлас.

Так что я надеюсь, что этот небольшой лакомый кусочек поможет вам стратегически представить свой безголовый стек в будущем. Если вы хотите двигаться именно в этом направлении, я настоятельно рекомендую вам взглянуть на Atlas. Я надеюсь, что вам понравился сеанс, и большое спасибо.