DE{CODE}: когда выбирать Headless для клиентов

Когда у клиента есть требования к производительности и безопасности, когда агентству следует выбирать традиционный WordPress или безголовый WordPress для работы? Узнайте больше на этом сеансе DE{CODE} с участием группы экспертов агентства, которые оценивают преимущества, ограничения, возможности и компромиссы перехода на безголовые.

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

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

ХАШИМ УОРРЕН: Здравствуйте, добро пожаловать на нашу панель «Когда выбирать безголовый WordPress для клиентов». Итак, меня зовут Хашим Уоррен, и я менеджер по маркетингу продуктов Atlas, нашего решения для Headless WordPress. И один из первых вопросов, которые я получил от людей, когда они внедряют или хотят внедрить Headless WordPress, — это когда мне следует использовать традиционный WordPress, все в одном WordPress, и когда я должен использовать Headless WordPress.

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

Итак, сегодня со мной Джонатан Джетер, директор по техническому производству в Click Here Labs. У нас также есть Стивен Брукс, технический директор Springbox. У нас также есть Джеймс Сквайрс, главный технический директор Space 150. И у нас также есть Тайо Онабуле, управляющий директор Drawl.

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

ДЖОНАТАН ДЖИТЕР : Конечно. Итак, мы уже некоторое время заинтересованы в работе над Безголовым пространством. И главная причина, по которой мы были заинтересованы в этом, заключалась в том, что мы хотели создавать более крупные проекты, которые объединяли бы данные из нескольких источников. И WordPress API еще не был готов. Поэтому мы работали над разными способами представления внешнего интерфейса, по-прежнему используя контент из WordPress. Итак, это в основном то, чем мы занимаемся уже лет пять-семь, пытаясь выяснить, как это сделать лучше всего.

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

ХАШИМ УОРРЕН: Потрясающе. А Степан, у тебя есть похожая история? Например, что заставило вас или ваше агентство заинтересоваться Headless WordPress?

СТИВЕН БРУКС : Да, мы работаем в сфере Headless примерно с 2015 года, традиционно имея дело с CMS-платформами, основанными на джеме. За последние несколько лет было сложно иметь дело с некоторыми маркетинговыми командами, работающими внутри системы джемов, просто из-за смены парадигмы ввода контента, в отличие от подхода типа поста и страницы.

Мы также пытались, как и Джонатан, использовать WordPress API. Это немного громоздко, на самом деле не дает вам именно то, что вам нужно все время. Всякий раз, когда WP Engine упоминал Atlas и говорил о базовых технологиях, это был поцелуй шеф-повара с тем, что мы традиционно делали в джем-пространстве.

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

ХАШИМ УОРРЕН: Это потрясающе. Тайо, можете ли вы рассказать нам свою историю, и просто в продолжение, можете ли вы рассказать нам о том, как убедить издателей принять Headless WordPress?

ТАЙО ОНАБУЛЕ : Да. Так что я имею в виду, что в нашем случае у нас был немного более свежий и немного другой вход в пространство безголового WordPress. Одним из основных драйверов для нас является один из наших клиентов Android Authority, который имеет довольно широкий охват. Что-то на данный момент намекает на отметку в 20 миллионов посетителей в месяц.

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

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

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

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

ХАШИМ УОРРЕН: Это потрясающе. Итак, до сих пор мы слышали о производительности SEO, гибкости для разработчиков, гибкости с точки зрения типа проекта, а также о том, что издатели могут придерживаться знакомой им CMS. Джимми, соответствует ли ваш опыт чему-либо из вышеперечисленного, или вам есть что добавить в плане того, что привлекло вас или ваше агентство в Headless WordPress?

ДЖЕЙМС СКВАЙРЕС: Да, я думаю, что у нас много общего. Одна вещь, которую я, вероятно, добавлю, может показаться немного эгоистичной поначалу, но я как бы доберусь до этого, и почему это хорошо. Но на самом деле для нас это было действительно обусловлено удовлетворением разработчиков.

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

ХАШИМ УОРРЕН: Это потрясающе. Одна из вещей, которую многие наблюдатели слышали на конференциях, — это разница между разработкой на основе тем для WordPress и разработкой на основе компонентов. Кто-нибудь может говорить об этом? Преимущества использования компонентного подхода при создании веб-сайтов?

ТАЙО ОНАБУЛЕ: Да, я действительно хотел бы перейти к этому, на самом деле. Точно так же, я уверен, что у всех нас есть примеры этого, но я думаю, что одна из самых приятных вещей, которые происходят, когда вы работаете с библиотеками JavaScript, такими как React, во всяком случае, по нашему опыту, это да, как вы говорите, доступ к такому стилю построения, основанному на компонентах.

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

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

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

СТИВЕН БРУКС: Да, не только это, Тайо. Но есть и другие большие преимущества. Я имею в виду, что вы действительно ударили по голове за часть удовлетворенности разработчика, но если вы посмотрите на традиционную разработку на основе шаблонов, в отличие от разработки на основе компонентов, модульное тестирование, правильно. Очень сложно реализовать какое-либо модульное тестирование внутри тематического подхода. С компонентом, бум, это прямо для вас.

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

ДЖОНАТАН ДЖИТЕР: И нам пришлось обучать наш креативный персонал, потому что они так привыкли, что на этом сайте 5 шаблонов, а на этом что-то еще. Мы такие, нет, не уйти от этого, верно. И вот мы закончили тем, что назвали его. Просто создайте страницу кухонной раковины, правильно, одну страницу со всем, правильно, и мы создадим ее оттуда. Так что да, это значительно упростило разработку, но нам пришлось обучать персонал по всем направлениям, чтобы убедиться, что они понимают, что мы делаем и как мы это создаем.

ДЖЕЙМС СКВАЙРЕС: Да, даже в операциях. Я имею в виду, когда мы делаем это, изменилось то, как формируются наши предложения для клиентов. Мы говорим о количестве блоков и о том, как мы их создаем, а не о шаблонах. И я думаю, что это такой сдвиг парадигмы для некоторых, особенно в области маркетинга, чтобы подумать: у вас есть бесконечные страницы с различными типами блоков. На самом деле это основные блоки и компоненты, а также то, что мы создаем и анализируем.

ТАЙО ОНАБУЛЕ: И последнее. И я думаю, что упоминание о предложениях — это действительно хороший момент, потому что процесс безголового в значительной степени меняет любые оценки, которые у вас могут быть в отношении того, что потребуется для новой функции или нового макета страницы. Дело в том, что он очень последовательно уменьшается с течением времени. Чем шире ваша библиотека компонентов, тем меньше времени требуется для добавления дополнительного стиля или чего-то еще, настройки стиля для всего сайта, добавления нового макета страницы. Все эти вещи становятся все легче и легче.

И я думаю, что это приятно для всех, если честно.

ХАШИМ УОРРЕН: Это действительно интересно. Это не просто Headless против сайта «все в одном», это разработка на основе шаблонов, а не на основе компонентов. И похоже, что это касается цитирования, работы с клиентом и его одобрения, тестирования и работы по обеспечению качества, разработки и проектирования. И, похоже, есть сдвиг. И, кажется, есть положительный сдвиг. Есть что-нибудь-

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

СТИВЕН БРУКС: Да, конечно. Итак, первое, на что я лично смотрю, — это след безопасности, который нужен организации, верно. Это внутренний веб-сайт или внешний веб-сайт? После этого мы начинаем смотреть, эй, будет ли эта CMS поддерживать несколько элементов, многоканальную доставку. Если эти первые два поля отмечены галочкой, бум, это автоматическая сборка без головы.

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

ХАШИМ УОРРЕН: Нет, это потрясающе. Джонатан, можешь немного поговорить об этом? Какой набор требований заставит вас подумать: «Хорошо, это должен быть проект без головы»? А также, какие компромиссы вы бы объяснили клиенту при принятии Headless?

ДЖОНАТАН ДЖЕТЕР: Конечно, поэтому один из основных вопросов, о котором говорилось выше, — сколько источников данных вы используете для агрегирования контента для сайта? И хочет ли клиент использовать это как центральное хранилище контента, в отличие от этого и восьми других источников, которые у них есть для своего мобильного приложения, или для своих медиа, или для чего-то еще, верно?

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

Но компромиссы. Один - цена. Это дороже, это обслуживание, правильно. Так что теперь вы не просто поддерживаете WordPress, верно, вы поддерживаете два разных стека, два разных приложения. Вот почему мы пошли по этому пути, и мы использовали все AWS и Gatsby, и все эти вещи, чтобы сделать это заранее. Итак, мы все были в деле, когда появился Атлас. Мы подумали, о да, если бы мы могли сделать все это в одном месте.

Потому что в течение многих лет мы разговаривали с нашим движком WP, и я сказал, что вам, ребята, нужно сделать это, потому что мы делаем это где-то еще, верно. Итак, давайте все вместе. Мы были в восторге от этого. Очень-очень доволен процессом создания сайтов в Атласе. Но компромисс — это в основном обслуживание, которое уходит с Atlas. Стоимость для клиента, что касается хостинга, в отличие от стандартного сайта WordPress.

Но иногда, как я уже говорил, стоимость разработки сайта снижается, стоимость обслуживания сайта снижается. Так что это компромисс.

ДЖЕЙМС СКВАЙРЕС: Я думаю, что еще один очень важный момент, который мы учитываем при обсуждении того, подходит ли он для подхода, основанного на теме, или безголового, — это то, как выглядит передача после создания сайта? Ожидает ли клиент, что у него есть внутренние ресурсы, которые берут на себя эту задачу? Или они ищут долгосрочного партнера-агентства, на которого можно положиться?

И это действительно важное решение, потому что если у вас есть команда, которая не знакома, скажем, с React, Gatsby или Next, каким бы ни был стек Headless, то это может стать довольно большим сюрпризом, если они не знакомы с Безголовая архитектура и как ее поддерживать. Итак, это что-то действительно важное, может показаться очевидным, но просто для ясности: хорошо, как только эта штука запустится, и мы перейдем в режим обслуживания и передачи, каков план?

ХАШИМ УОРРЕН: Потрясающе.

ТАЙО ОНАБУЛЕ: Я думаю, что еще одна вещь, которая, я думаю, Джонатан упомянул, это своего рода тот факт, что, и это в значительной степени то, на чем мы сосредотачиваемся как агентство, то, что позволяет Безголовый, в первую очередь, опыт вещь. С точки зрения того, с чем взаимодействуют ваши пользователи. И так часто, и это меняющийся разговор для каждой компании. Некоторые компании просто хотят, чтобы работа была сделана. Некоторые компании хотят быть кричащими об этом.

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

Потому что, очевидно, WordPress уже давно делает это, и это надежное место для создания сайта, но в целом, сколько «яркого яркого» вы хотите? А если хочется многого, то Безголовый - действительно отличный способ

ХАШИМ УОРРЕН: Это потрясающе. Джимми, я хочу поговорить о кадрах с точки зрения агентства. Когда вы думаете о проектах без головы, вам нужны разработчики WordPress, которые приняли JavaScript и, скажем, что-то вроде React? Или вы бы предпочли больше разработчика JavaScript, который даже не использует WordPress? Например, что вы думаете о персонале, когда речь идет о проектах Headless WordPress?

ДЖЕЙМС СКВАЙРЕС: Да, это хороший вопрос. Наше агентство, мы ищем React как своего рода базовую линию, поэтому, очевидно, JavaScript и опыт работы с фреймворком React. Это вроде нашего обязательного, на всех уровнях, на самом деле. WordPress — это — мы относимся к этому как к «приятному». Это то, что особенно в Безголовом пространстве мы можем обучить относительно быстро.

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

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

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

ХАШИМ УОРРЕН: Это тоже очень интересно с точки зрения возможности разделять работу. Вы работаете над этим компонентом, и вы можете работать над ним отдельно от проекта. Это действительно отличный пример.

Джонатан, что вы думаете об этом, когда речь идет о безголовых проектах WordPress? Вы бы предпочли иметь разработчика WordPress с навыками, который добавляет к этому React или любой другой фреймворк JavaScript? Или разработчик JavaScript, который масштабируется на WordPress, как вы об этом думаете?

ДЖОНАТАН ДЖЕТЕР: Итак, как сказал Джимми, нам нужно и то, и другое, но сейчас мы собираемся больше искать React, View, разработчиков интерфейса JavaScript. Что ж, теперь все называют себя Full Stack, но разработчики JavaScript, которые смогут вмешаться. И у меня были разработчики, которые приходили и говорили: «О, я не собираюсь работать в WordPress, как будто это не что-то». Я хочу делать. И как только мы приступаем к этому, мы делаем проект Headless, о, это не так уж и плохо.

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

ДЖЕЙМС СКВАЙРЕС: Я собирался добавить к этому, по крайней мере, исходя из нашего опыта, что количество инженеров, которых вы можете привлечь в проект без головы и которые будут продуктивными, как правило, намного выше. Например, на прошлой неделе мы только что запустили Headless на основе SvelteKit — я думаю, что это первый продукт на Atlas. Я пока не рекомендую SvelteKit клиентам, но нам он очень нравится.

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

ХАШИМ УОРРЕН: Между прочим, это прекрасное зрелище. Я видел запуск. Это прекрасный сайт.

ДЖЕЙМС СКВАЙРЕС: Спасибо.

ДЖОНАТАН ДЖЕТЕР: Еще я хотел бы сказать, что я знаю, что мы говорим только о WordPress, верно, но мы имеем дело и с проектами, которые не являются WordPress, верно. Таким образом, эти разработчики JavaScript могут работать с несколькими серверными системами, в отличие от того, если бы я нанял разработчика .net, они работают, по большей части, только в .net, правильно.

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

ТАЙО ОНАБУЛЕ: И я думаю, что здесь есть несколько вещей, о которых мы все как бы упоминаем. Я думаю, давайте скажем так, как React, один… В нашем случае мы все равно склонны придерживаться React. У нас есть несколько разработчиков View, но мы склонны придерживаться React. Но все эти интерфейсные фреймворки были разработаны специально с учетом типа разработчика и процесса. Они разработаны — я полагаю, что мистер Facebook в какой-то момент сказал: «Давайте позаботимся о том, чтобы это было максимально эффективно для нашей команды».

Итак, это ядро ​​React, и оно будет во многом таким же для View и Angular. С точки зрения WordPress, еще раз, назовите это так, как оно есть. По сути, вы могли бы обойтись, просто зная, как перемещаться по серверной части WordPress и используя ACF. В противном случае у вас нет знаний о WordPress, и вы все равно можете создать сайт WordPress без головы.

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

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

ХАШИМ УОРРЕН: Я просто хочу подтвердить вашу историю, потому что в прошлой жизни мне пришлось обучать двух разработчиков React нашему новому сайту WordPress. И это был безголовый сайт WordPress. И это был только полдень. Я показал им ACF, они были очень взволнованы, они сделали модели данных, и они были в восторге. И даже один из разработчиков действительно подключил классический редактор, и сделал так, чтобы я мог управлять некоторыми компонентами на фронтенде.

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

ТАЙО ОНАБУЛЕ: Дело в том, что такие фронтенд-разработчики привыкли подключаться к серверной части для своих данных и иметь структуру данных, которой можно придерживаться. Это обычная составляющая их рабочего процесса, поэтому у WordPress нет особых шансов.

ДЖОНАТАН ДЖЕТЕР: С преобладанием… извините, преобладанием SaaS, приложениями, доступными теперь везде, вещами, которые вы раньше делали в WordPress, будь то электронная коммерция, будь то интеграция с CRM и все такое. Теперь это не делается в — это больше не нужно делать в WordPress. Вам не нужно устанавливать плагин Marketo или плагин Salesforce или что-то еще, чтобы попытаться подключить их, верно.

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

ХАШИМ УОРРЕН: Потрясающе. Стивен, я хотел бы услышать от вас об экосистеме, экосистеме JavaScript. Я знаю, что разработчики WordPress привыкли к действительно потрясающей, надежной экосистеме с точки зрения плагинов и сообщества. Можете ли вы рассказать о том, как это можно сравнить, возможно, с экосистемой в мире JavaScript? И с точки зрения технологий, и даже с точки зрения сообщества.

СТИВЕН БРУКС: Да, так что с WordPress у него самый большой рынок плагинов для традиционной монолитной сборки. Но вернемся к точке зрения Джонатана секунду назад, с использованием NPM для всех ваших функций, которые вам нужны от внешнего интерфейса, это эквивалентно, если не лучше, чем рынок WordPress. Потому что у вас есть не только все доступные пакеты NPM. Существует также множество STK, которые вы также можете использовать, чтобы действительно быстро создать всю необходимую интеграцию данных.

Так что я бы почти сказал, что это больше примерно на 20%. Просто выбрасывая произвольное число, но люди двигаются намного быстрее. И многое из того, что связано с NPM, на высоте. Вам также не нужно беспокоиться о несоответствии версии ядра WP и версии плагина, которые могут произойти. Как только вы закрепите свои версии в манифесте пакета, я имею в виду, что все готово. Вам больше не нужно беспокоиться об их обновлении, если вы этого не хотите, или что-то в этом роде.

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

ДЖЕЙМС СКВАЙРЕС: Не хочу бросать тень на компании, которые зарабатывают много денег на своих плагинах WordPress, но это другая область, поскольку вы просто стремитесь к тому, чтобы в безголовой архитектуре было меньше затрат на лицензирование, тогда как в типичной основанной на теме есть некоторые действительно отличные плагины, которые мы всегда превращаем в предложения для покупки и использования. По большей части все в NPM является бесплатным программным обеспечением с открытым исходным кодом.

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

ХАШИМ УОРРЕН: Джимми, у меня есть еще один подобный пример. Итак, я создавал веб-сайт Gatsby и добавлял к нему Google Analytics. У Gatsby есть экосистема плагинов, все плагины с открытым исходным кодом. Их пакеты находятся в NPM, их легко установить. Итак, я добавляю Google Analytics, и у него есть все эти опции, которые с самым популярным плагином Google Analytics для WordPress некоторые из этих опций входят в премиум-версию. Так что я был очень взволнован как человек, который счастлив заплатить за этот плагин WordPress, чтобы иметь ту же функциональность с этим пакетом, который также был плагином Gatsby. Так что я очень взволнован тем, как эти экосистемы соответствуют друг другу.

ТАЙО ОНАБУЛЕ: Я думаю, что это было очень быстро и по всей теме НПМ. Я думаю, что это всего лишь мельчайшая вещь, и это, вероятно, несущественно, но я для меня. Я предпочитаю тот факт, что когда вы что-то разрабатываете в React, вам нужно что-то, вы загружаете это через CLI. И вам не нужно заходить в WordPress или что-то еще, это просто там, в вашем пространстве. Вам не нужно покидать студию, и все это там. И это гораздо менее громоздкий процесс, чем исследование, поиск плагина, его установка и так далее. Я никогда не был фанатом этого.

ХАШИМ УОРРЕН: Потрясающе. Джонатан, я хочу спросить вас, мы говорили о требованиях, которые заставят вас сказать, что это идеально подходит для Headless WordPress. Какой проект заставит вас почувствовать, что это, хорошо, это должен быть традиционный проект WordPress.

ДЖОНАТАН ДЖИТЕР: Мы тоже много чего делаем, да. Иногда это бюджет. Они приходят и говорят, у нас столько. Мы такие, выбора нет, верно. Это то, что мы делаем, правильно. И потому, что у нас есть вещи, которые мы используем. Этот процесс и эта система уже существуют. Как сказал Джимми, у нас есть плагины, которые мы встраиваем в каждое из этих предложений, потому что мы знаем, что это очень просто.

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

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

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

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

ХАШИМ УОРРЕН: Потрясающе. Стивен, можно поговорить об этом? When would you say, OK, this needs to be a traditional site or traditional WordPress site?

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John's talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it's still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me.

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Atlas Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.