DE{CODE}: Гутенберг и безголовый WordPress

Гутенберг, также известный как блоки WordPress, дает производителям контента новые мощные способы размещения контента на традиционном сайте WordPress. Но как безголовые разработчики WordPress могут предоставить маркетинговым командам такие же возможности? В этом сеансе DE{CODE} основатель GraphQL для WordPress (WPGraphQL) Джейсон Бал делится новыми возможностями и рекомендациями по использованию редактора блоков WordPress на безголовом сайте.

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

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

ДЖЕЙСОН БАЛ : Привет. Добро пожаловать на мой доклад о Гутенберге и безголовом WordPress. Меня зовут Джейсон Бал. Я создатель и сопровождающий WPGraphQL. Я главный инженер-программист в WP Engine. Вы можете найти меня в Твиттере @jasonbahl или в Твиттере @wpgraphql.

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

Итак, у WordPress исторически был редактор, который выглядел примерно так. У нас есть текстовая область TinyMCE, где мы можем редактировать наш контент. Мы можем вставлять мультимедиа, а затем публиковать наш контент, а затем в 2018 году появился Gutenberg, этот блочный редактор, который позволяет нам вставлять контент в этот пустой холст и взаимодействовать с нашим контентом на уровне блоков.

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

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

С Headless WordPress вы по-прежнему используете WordPress в качестве CMS. Вы по-прежнему публикуете контент, курируете контент, администрируете контент в WordPress, но вместо того, чтобы доставлять страницу в HTML в браузер, WordPress предоставляет данные, как правило, в формате JSON, а затем клиентские приложения могут использовать эти данные, чтобы у нас были собственные приложения для iOS или Android. или даже приложений виртуальной реальности.

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

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

Итак, есть два распространенных способа использования этих данных. Мы можем получить данные в формате JSON из WP REST API, который является встроенным API для WordPress, и есть еще один API, называемый WPGraphQL. Это плагин с открытым исходным кодом, который вы можете установить и получать данные из WordPress и JSON. И сегодня мы поговорим о WPGraphQL.

Итак, теперь, когда мы знаем, что такое WordPress, почему вы можете создавать безголовые проекты WordPress? Как я уже упоминал, у вас есть большая гибкость при выборе технологии внешнего интерфейса. И для некоторых людей очень важно иметь возможность выбирать, как они будут создавать интерфейсные проекты. Есть некоторые фреймворки, такие как Next, Gatsby и Svelte, которые действительно нацелены на улучшение основных жизненно важных веб-приложений. Таким образом, вы можете перейти на WordPress без головы и улучшить основные веб-жизненные показатели.

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

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

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

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

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

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

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

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

Итак, если мы снова посмотрим на опыт разработчиков WordPress, мы опубликуем наш контент в одном поле, которое генерирует большой кусок HTML. И даже если мы используем редактор Гутенберга, в котором есть такие детализированные блоки, конечным результатом будет один большой кусок HTML. Итак, публикуем ли мы в Гутенберге или традиционном классическом редакторе, этот фрагмент HTML отправляется через PHP в нашу тему, и у нас есть одна глобальная страница, которая загружает наш HTML, наш CSS и наш JavaScript. И эти активы применяются к странице глобально.

Таким образом, разработчики WordPress, как правило, разделяют нашу разработку на основе типов файлов, поэтому мы помещаем наш CSS в отдельные файлы, которые применяются глобально к странице, или HTML будет написан на PHP, и извлечение необходимых нам данных из WordPress, а затем JavaScript часто пишутся с помощью jQuery в отдельных файлах. Итак, эти три вещи сойдутся вместе, чтобы создать страницу.

Проблема в том, что они не изолированы, они применяются ко всей странице. Так что иногда можно внести изменения. Как это случилось со мной. Однажды я изменил стиль в нижнем колонтитуле сайта по просьбе моего менеджера, а через три дня мне сообщили, что стиль где-то еще на сайте изменился из-за проверки кода. Мы прошли это.

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

И мы можем объединить наш JavaScript, наш HTML, наш CSS в небольшие фрагменты, которые мы можем тестировать изолированно, и таким образом мы можем создавать части нашего приложения. Несколько проблем, разметка, JavaScript, стили, и мы можем составить эти компоненты вместе для создания более сложных приложений.

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

Таким образом, он имеет зависимости от разметки. Он имеет зависимости от стиля. У него могут быть взаимодействия с состоянием. Все они связаны с этим конкретным компонентом. Таким образом, мы можем объединить нашу разметку, наш JavaScript и наш CSS в одном месте, протестировать их и убедиться, что они работают правильно. Благодаря этому мы можем повторно использовать эти компоненты во всем нашем приложении или даже повторно использовать наши компоненты в разных проектах.

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

Так как же тогда мы можем использовать Headless WordPress? Как я упоминал ранее, есть два способа получить данные из WordPress и в компоненты. Одним из них будет REST API. Одним из них будет WPGraphQL. Мой друг Дрейк некоторое время занимался созданием сайтов без голов, поэтому я спросил его, и вот что он сказал…

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

Хорошо, Джейсон. Я все еще не понимаю, что ты говоришь. Ладно, позвольте мне показать вам. Итак, GraphQL работает так, что клиентские приложения отправляют запрос, указывающий, что они хотят от сервера. И запрос выглядит примерно так. Похоже на ключи JSON без значений. Таким образом, в этом случае запрос запрашивает средство просмотра, а для средства просмотра мы хотим вернуть поле «имя».

И ответ от сервера GraphQL может выглядеть так. Его фактические данные JSON, ключи и значения соответствуют форме запроса. Так что в этом случае мы получаем имя или зрителя с именем Джейсон Бахл. Итак, GraphQL позволяет клиентским приложениям вырывать деревья из графа данных приложения.

И то, как это выглядит визуально, примерно так. Мы можем войти в граф, скажем, добавить просмотрщик или пользовательское поле или узел. И этот узел может иметь такое свойство, как имя Джейсон. И этот узел может иметь соединения с другими узлами в графе, такими как аватар, который может иметь свойство, такое как URL-адрес изображения.

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

И поэтому мы можем использовать инструменты в админке GraphQL или в админке WordPress. Есть инструмент под названием GraphiQL, где я могу составить запрос. И здесь я выбираю поле Viewer с подвыборками, именем, аватаром, URL-адресом, и когда мы его выполняем, мы получаем запрашиваемые поля, и визуально этот запрос выглядит примерно так.

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

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

И мы можем посмотреть на код, и мы видим, что у нас есть некоторый контроль стиля. Мы можем установить ширину, мы можем передать ему изображение, которое мы хотим, и мы можем передать ему заголовок. Таким образом, мы можем повторно использовать этот компонент во всем нашем проекте. И этот компонент имеет все необходимые нам зависимости. У него есть HTML для рендеринга. У него есть стили. Здесь у нас есть некоторый контроль над стилем. Он имеет некоторые компоненты с состоянием, такие как состояние наведения и еще много чего.

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

У нас есть HTML, CSS — наш JavaScript. И из-за данных у нас теперь есть что отображать с данными, которые мы запросили. Так что теперь мы можем использовать это во всем нашем приложении, и в GraphQL есть функция, называемая фрагментами, и это позволяет нам брать наши запросы GraphQL и разбивать их на повторно используемые части.

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

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

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

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

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

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

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

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

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

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

Итак, в настоящее время состояние разработки WordPress с Gutenberg таково, что у нас есть блоки на серверной части, основанные на компонентах. Мы можем создавать собственные блоки или использовать основные блоки WordPress. Но вывод в PHP, как я уже упоминал, это один большой кусок HTML, и как мы можем перейти от получения этого одного блока HTML к компонентам на серверной части, которые также передаются компонентам на нашем интерфейсе?

Итак, мы собираемся рассмотреть некоторые варианты переноса данных Gutenberg из WordPress в компоненты. Таким образом, один из вариантов — получить контент в виде HTML. Таким образом, мы можем запросить наш контент WordPress как HTML, а затем разобрать этот HTML на компоненты. Или мы можем запрашивать блоки как типы GraphQL. Итак, мы можем — это позволяет нам запрашивать список блоков, каждый блок будет типом GraphQL, который мы можем сопоставить с компонентом.

Таким образом, содержимое HTML. Это то, что мы можем сделать в ядре WPGraphQL уже сегодня. Если вы хотите запрашивать блоки как отдельные типы GraphQL, на данный момент есть два варианта. У нас есть расширение GraphQL для Gutenberg, которое является расширением сообщества, а затем у нас есть редактор блоков WPGraphQL, бета-плагин, над которым я работаю лично.

И так давайте рассмотрим эти варианты. В ядре WPGraphQL мы можем запрашивать содержимое как HTML и анализировать его на компоненты. Это выглядит так: мы запрашиваем что-то вроде поста и можем запрашивать такие поля, как ID, заголовок или контент. И контент будет возвращать одну большую строку, один большой кусок HTML, а затем мы сможем разобрать этот HTML и сопоставить разные узлы DOM с разными компонентами.

Как и в этом случае на wpgraphql.com, ссылка слева ведет на код, в котором это происходит на самом деле. Я беру разметку, возвращаемую WPGraphQL, анализирую ее, ищу определенные узлы HTML и преобразовываю в компоненты React. Таким образом, у меня могут быть интерактивные вещи, такие как этот блок кода, который выделяет синтаксис и позволяет пользователям нажимать «Копировать», а затем я также могу анализировать и создавать оглавление, например. Так что это один подход. И сегодня я использую его на wpgraphql.com.

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

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

Один из других вариантов, WPGraphQL для Gutenberg, это плагин, поддерживаемый сообществом. И это позволит вам запрашивать блоки контента, каждый блок как свой собственный тип GraphQL. Это работает на странице настроек, вам нужно ввести только блоки в качестве схемы, поэтому Гутенберг открывается в невидимом iframe, получает реестр блоков от клиента JavaScript и отправляет его на сервер.

И затем мы можем использовать GraphQL для запроса наших блоков как определенных типов, и мы можем использовать фрагменты, как я показал ранее, и мы можем использовать эти фрагменты для сопоставления с компонентами на нашем внешнем интерфейсе. Так что это один из вариантов. Некоторые соображения относительно этого плагина: изменения в реестре блоков можно наблюдать самостоятельно, так что это хорошо.

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

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

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

Некоторые соображения по этому поводу, это бета-плагин, так что вот что. Вы получаете выгоду от структурированного ввода и структурированного вывода. Так что, как интерфейсный разработчик, это, безусловно, победа. Он работает с блоками, зарегистрированными в файле block.json. Таким образом, в основных блоках WordPress Gutenberg есть этот файл, и это будет работать с таким подходом. Многие третьи лица не регистрируют свои блоки таким образом, поэтому вам придется сопоставлять эти блоки вручную.

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

Надеюсь, вы узнали кое-что о Headless WordPress, преимуществах Headless WordPress и использовании Headless WordPress с Gutenberg. Я приглашаю вас попробовать WPGraphQL сегодня. Вы можете зарегистрировать бесплатную учетную запись Atlas Sandbox на странице wpengine.com/atlas. И спасибо, что присоединились к моей презентации. Опять же, вы можете найти меня в Твиттере, jasonbahl, а также в Твиттере @wpgraphql. Спасибо.