DE{CODE}: Quando escolher Headless para clientes

Quando um cliente tem requisitos de desempenho e segurança, quando uma agência deve escolher o WordPress tradicional ou o WordPress headless para o trabalho? Saiba mais nesta sessão DE{CODE}, apresentando um painel de especialistas em agências que avaliam os benefícios, restrições, oportunidades e compensações de ficar de cabeça para baixo.

Slides da Sessão

Transcrição de texto completo

HASHIM WARREN: Olá, bem-vindo ao nosso painel, Quando escolher o WordPress sem cabeça para clientes. Então, meu nome é Hashim Warren e sou o Gerente de Marketing de Produto da Atlas, nossa solução para Headless WordPress. E uma das primeiras perguntas que recebo das pessoas quando estão adotando, ou querem adotar o Headless WordPress, é quando devo usar o WordPress tradicional, tudo em um só WordPress, e quando devo usar o Headless WordPress.

Portanto, se eu tiver um cliente com requisitos de desempenho e segurança, como devo pensar em adotar ou escolher Headless ou WordPress tradicional. E também, se eu escolher o Headless WordPress, o que devo esperar, no que estou me metendo aqui. Portanto, hoje temos um excelente painel com experiência em projetos WordPress tradicionais e também em projetos Headless WordPress que poderão responder a algumas das grandes perguntas que sei que muitos de vocês têm.

Então, hoje comigo temos Jonathan Jeter, que é o diretor de produção técnica do Click Here Labs. Também temos Stephen Brooks, diretor de tecnologia da Springbox. Também temos James Squires, diretor de tecnologia da Space 150. E também temos Tayo Onabule, diretor administrativo da Drawl.

Então, eu só quero trazer o painel agora, para que possamos começar esta conversa. Então vamos começar a conversa desta forma. Apenas me diga o que fez você pessoalmente, ou sua agência, se interessar pelo Headless WordPress em primeiro lugar. E Jonathan, você pode começar?

JONATHAN JETER : Claro. Por isso, já faz um tempo que estamos interessados ​​em trabalhar no espaço Headless. E o principal motivo pelo qual estávamos interessados ​​era porque queríamos criar projetos maiores que integrassem dados de várias fontes. E a API do WordPress ainda não estava lá. Então, estávamos trabalhando em diferentes maneiras de apresentar a camada de front-end, ainda usando o conteúdo do WordPress. E então, isso é basicamente o que temos feito por cerca de cinco a sete anos, tentando descobrir qual é a melhor maneira de fazer isso.

E agora é muito mais fácil do que era, obviamente há muito mais – há uma variedade de opções de como você vai fazer isso. E assim, vimos o espaço crescer e estamos muito animados com o rumo que está tomando. Isto

HASHIM WARREN: Incrível. E Stephen, você tem uma história parecida? Como o que fez você ou sua agência se interessar pelo Headless WordPress?

STEPHEN BROOKS : Sim, estamos no espaço Headless desde 2015, lidando tradicionalmente com plataformas CMS baseadas em jam. Nos últimos anos, tem sido um desafio lidar com algumas equipes de marketing trabalhando dentro de um sistema de jam, apenas por causa da mudança de paradigma na entrada de conteúdo, em oposição a uma abordagem de postagem e tipo de página.

Também tentamos, assim como Jonathan, aproveitar a API do WordPress. Isso é um pouco complicado, não dá exatamente o que você precisa o tempo todo. Sempre que o WP Engine mencionava o Atlas e falava sobre as tecnologias subjacentes, era um beijo de chef com o que tradicionalmente fazíamos no espaço de jam.

Portanto, agora é uma conversa muito fácil com nossos clientes, porque quase todos os profissionais de marketing têm experiência em trabalhar com o WordPress, mas os desenvolvedores obtêm o benefício adicional de uma solução Headless. Assim, você obtém mitigação de riscos de segurança, bem como apenas algumas das interações de primeira linha com uma camada de apresentação baseada em React. Então esse tem sido nosso verdadeiro driver aqui recentemente.

HASHIM WARREN: Isso é incrível. Tayo, você pode nos contar sua história e, só para acompanhar, pode nos contar sobre como convencer os editores a adotarem o Headless WordPress?

TAYO ONABULE : Sim. Quer dizer, acho que, no nosso caso, tivemos uma entrada um pouco mais recente e um pouco diferente no espaço Headless WordPress. Um dos principais impulsionadores para nós é um de nossos clientes, o Android Authority, que tem um alcance bastante amplo. No momento atual, meio que insinuando a marca de 20 milhões de visitantes mensais.

E suas necessidades são bastante simples de certa forma. Eles precisam de um SEO realmente bom, como de primeira linha. E eles têm muitos concorrentes muito competentes ao seu redor. Então, sim, ótimo SEO, ótimo desempenho e ótima experiência de leitura para todos os artigos que eles publicam.

Portanto, Headless foi realmente - realmente surgiu para nós como parte da conversa, quando estávamos tentando fazer tudo o que podíamos para encontrar uma maneira de fazer com que seus sites WordPress existentes atendessem a todas essas necessidades. Realmente ao máximo, basicamente. E Headless, primeiro foi o caso de eu apenas fazer algumas pesquisas e pensar, oh, bem, talvez pudéssemos, talvez tentar.

E fomos cada vez mais fundo e passamos pelo processo de convencer a equipe. Mas, à medida que avançamos em todo o desenvolvimento, começamos a perceber que, sim, ele respondeu a todas as perguntas principais, como desempenho de SEO e experiência, mas também nos deu total flexibilidade ao longo dos anos. sobre.

Lançamos, acredito que foi em maio do ano passado, então estamos chegando no aniversário disso, na verdade. , Mas sim, desde o lançamento conseguimos criar um grande número de integrações no site. Tudo isso teria sido consideravelmente mais difícil se estivéssemos em monolítico ou tudo em um WordPress. Essa flexibilidade que ele oferece é uma das... é uma das coisas que eu estava dizendo ao Android Authority que teríamos, mas acho que não percebi bem a escala e a liberdade que ele oferece, basicamente.

HASHIM WARREN: Isso é incrível. Então, até agora ouvimos sobre desempenho de SEO, flexibilidade para desenvolvedores, flexibilidade em termos de que tipo de projeto, também os editores podem ficar com um CMS que eles conhecem. Jimmy, sua experiência corresponde a isso ou você tem algo a acrescentar em termos do que atraiu você ou sua agência para o Headless WordPress?

JAMES SQUIRES: Sim, acho que muitas dessas coisas que compartilhamos também. A única coisa que eu provavelmente acrescentaria que talvez pareça um pouco egoísta no começo, mas eu meio que chegarei lá e por que é uma coisa boa. Mas, na verdade, para nós, foi realmente motivado pela satisfação do desenvolvedor.

Viemos principalmente de um background de framework baseado em React e React, meio que entrando no WordPress. E nossos clientes estavam exigindo o WordPress cada vez mais, mas nossos engenheiros realmente não estão tão satisfeitos com o desenvolvimento baseado em temas na maior parte do tempo. Ainda fazemos isso quando ainda há aplicativos em que isso faz muito sentido, mas se seus desenvolvedores estão satisfeitos com o produto e com o que estão construindo, acho que a saída é muitas vezes você obtém uma experiência estelar para que haja é um benefício real para nossos clientes, embora nosso salto para isso tenha sido realmente centrado em algo que nossos engenheiros queriam fazer.

HASHIM WARREN: Isso é incrível. Uma das coisas que muita gente que está assistindo já deve ter ouvido nas conferências, é a diferença entre desenvolvimento baseado em temas para WordPress e desenvolvimento baseado em componentes. Alguém pode falar sobre isso? Os benefícios de adotar uma abordagem baseada em componentes ao criar sites?

TAYO ONABULE: Sim, eu realmente gostaria de entrar nisso, na verdade. Assim como, tenho certeza de que todos nós temos exemplos disso, mas acho que uma das coisas mais satisfatórias que acontecem quando você trabalha com bibliotecas JavaScript, como a do React, em nossa experiência, é sim, como você diz, acesso a esse tipo de estilo de construção baseado em componentes.

E isso significa que, por um lado, você pode dividir todo o design do site nessas partes componentes que são muito mais flexíveis. Digamos, por exemplo, que você tenha um bloco em uma página com dois estilos diferentes. Um, onde a imagem está do lado esquerdo e o texto está do lado direito, digamos. Apenas como uma espécie de exemplo simples. E React, esse é o caso de você ter um bloco com um modificador, essencialmente, para apenas dizer, inverter a ordem do texto e da imagem.

Quando estamos falando de monolítico, você está essencialmente apenas, sim, talvez você comece na mesma base, mas você rapidamente tem que separar os dois, e você tem duas coisas separadas agora. E as mudanças, até certo ponto, precisam ser distribuídas em duas coisas separadas. E é esse tipo de conceito que significa que, à medida que você entra em usos de escala cada vez maior para front-ends sem cabeça, essa flexibilidade e consistência que você pode ter executando em um site inteiro, em todos os usos de um componente específico, significa que o desenvolvimento , como James disse anteriormente, é muito mais satisfatório para os desenvolvedores.

É uma experiência consideravelmente melhor. Você pode realmente dizer que o React foi projetado para maximizar a produção dos desenvolvedores, e é isso, mais uma vez, como diz James, tudo isso é passado para o cliente. Porque eu acho que você pode dizer quando algo foi feito com amor e prazer, isso sempre resulta em um resultado melhor.

STEPHEN BROOKS: Sim, não apenas isso, Tayo. Mas também há alguns outros grandes benefícios nisso. Quero dizer, você realmente acertou na cabeça para a satisfação do desenvolvedor, mas se você der uma olhada no desenvolvimento tradicional baseado em modelo, em oposição a um desenvolvimento baseado em componente, teste de unidade, certo. É realmente difícil implementar qualquer tipo de teste de unidade dentro de uma abordagem baseada em tema. Com um componente, boom, está bem ali para você.

Mas quero acrescentar um ponto a isso, mas não é necessariamente para os desenvolvedores, é mais para os donos de empresas. Normalmente, com uma abordagem baseada em componentes, seu nível de esforço diminui significativamente em relação a uma determinada página de tema, porque seus componentes, você os reutilizará em todo o lugar, certo. E não requer um tempo adicional de digitação, digitação, para ir e adicionar esse bloco adicional onde quer que vá. Você acabou de construí-lo uma vez. Sempre que você o consome, você hidrata sua construção. Bum, acabou. É tão lindo, tão rápido. É maravilhoso.

JONATHAN JETER: E tivemos que treinar nossa equipe de criação, certo, porque eles estão acostumados a gostar, OK, este site tem 5 modelos, ou este é o que quer que seja. Nós pensamos, não, não vamos fugir disso, certo. E assim acabamos chamando. Basta projetar a página da pia da cozinha, certo, uma página com tudo nela, certo, e vamos construí-la a partir daí. Então, sim, tornou o desenvolvimento muito mais fácil, mas tivemos que treinar toda a equipe para garantir que eles entendessem o que estamos fazendo e como estamos construindo.

JAMES SQUIRES: Sim, mesmo em operações. Quero dizer, mudou a forma como nossas propostas para os clientes são moldadas quando estamos fazendo isso. Falamos sobre quantidades de blocos e como os construímos, em oposição a modelos. E isso é apenas uma mudança de paradigma, eu acho, para alguns, especialmente no lado do marketing, para pensar - você tem páginas infinitas de diferentes tipos de blocos. São realmente esses blocos e componentes principais e o que estamos construindo e delimitando.

TAYO ONABULE: E apenas uma última parte sobre isso. E eu acho que a menção de propostas é um ponto muito bom, porque o processo Headless muda massivamente qualquer tipo de estimativa que você possa ter sobre o que um recurso vai levar ou um novo layout de página vai levar. O fato é que diminui muito consistentemente ao longo do tempo. Quanto maior for a sua biblioteca de componentes, menos será necessário para adicionar um estilo adicional ou algo assim, ajustar um estilo em todo o site, adicionar um novo layout de página. Todas essas coisas se tornam cada vez mais fáceis.

E acho que isso é gratificante para todos, para ser sincero.

HASHIM WARREN: Então, isso é realmente interessante. Não é apenas Headless versus um site completo, é desenvolvimento baseado em modelo versus baseado em componente. E parece que aborda a cotação, o trabalho do cliente e a aprovação do cliente, o teste e o trabalho de controle de qualidade, o trabalho de desenvolvimento e o trabalho de design. E parece que há uma mudança. E parece que há uma mudança positiva. Há alguma coisa-

Então, se você tem um cliente que chega e ele diz, eu tenho requisitos xyz. Que conjunto de requisitos você ouviria que o faria dizer que isso é perfeito para um projeto sem cabeça? E Stephen, você pode começar?

STEPHEN BROOKS: Sim, claro. Portanto, a primeira coisa que vejo pessoalmente é a pegada de segurança de que a organização precisa, certo. Este é um site interno ou um site externo? Depois disso, começamos a dar uma olhada, ei, esse CMS vai alimentar vários itens, entrega omnicanal. Se essas duas primeiras caixas estiverem marcadas, boom, é uma construção sem cabeça automática.

Se apenas um deles for verificado, precisamos conversar um pouco mais profundamente com nosso cliente para garantir que esteja de acordo com sua pegada operacional. E quero dizer que 95% das conversas que tive nos últimos oito meses foram legais. Todo mundo gosta. É uma verdadeira mudança de paradigma em relação a todo o resto. Então sim.

HASHIM WARREN: Não, isso é incrível. E Jonathan, você pode falar um pouco sobre isso? Que conjunto de requisitos faria você se sentir como, OK, este deve ser um projeto Headless? E também quais compensações você explicaria a um cliente sobre a adoção do Headless?

JONATHAN JETER: Claro, então um dos principais, meio que direto ao ponto anterior, é quantas fontes de dados você está usando para agregar o conteúdo do site? E o cliente deseja usar isso como o repositório central de conteúdo, em oposição a esta e às outras oito fontes que ele possui para seu aplicativo móvel ou para sua mídia, ou para qualquer outra coisa, certo?

Então nós temos essa conversa. Se eles são como, oh sim, estamos todos dentro. E essa é uma escolha óbvia. Além disso, como agência de publicidade, temos esses tipos de criativos que estão sempre projetando essas coisas realmente malucas, certo. Então, se soubermos de antemão quem é o criativo, às vezes isso leva a uma conversa, sabemos que será mais fácil desenvolver como um aplicativo React do que tentar personalizar esse tema em WordPress.

Mas as compensações. Um é o preço. É mais caro, é manutenção né. Então agora você não está apenas mantendo o WordPress, certo, você está mantendo duas pilhas diferentes, dois aplicativos diferentes. É por isso que seguimos esse caminho e estávamos usando todos os AWS e Gatsby e todas essas coisas para fazer isso de antemão. E então, estávamos todos dentro quando Atlas apareceu. Nós pensamos, oh sim, se pudermos fazer tudo isso em um só lugar.

Porque há anos conversamos com nosso WP Engine, onde eu dizia, vocês precisam fazer isso porque estamos fazendo isso em outro lugar, certo. Então vamos juntar tudo. Então ficamos empolgados com isso. Muito, muito feliz com o processo de construção de sites no Atlas. Mas a desvantagem é basicamente a manutenção, que meio que desaparece com o Atlas. O custo para o cliente, no que diz respeito à hospedagem, em oposição a apenas um site WordPress padrão.

Mas às vezes, como eu disse antes, o custo de desenvolvimento do site diminui, o custo de manutenção do site diminui. Então é uma troca.

JAMES SQUIRES: Acho que outra coisa realmente importante que consideramos ao debater se é apropriado para uma abordagem baseada em tema ou Headless, é como fica a transferência após a construção de um site? O cliente espera ter recursos internos para assumir isso? Ou eles procuram um parceiro de agência de longo prazo em quem confiar?

E essa é uma decisão realmente crítica, porque se você tem uma equipe que não está familiarizada, digamos, React, Gatsby ou Next, qualquer que seja a pilha Headless, isso pode ser uma grande surpresa se eles não estiverem familiarizados com o Arquitetura sem cabeça e como ela será mantida. Então, isso é algo realmente importante, pode parecer óbvio, mas apenas para ser explícito, OK, uma vez que essa coisa for lançada e estivermos no modo de manutenção e transferências, qual é o plano?

HASHIM WARREN: Incrível.

TAYO ONABULE: Acho que a outra coisa, acho que Jonathan mencionou talvez, é o fato de que, e isso é em grande parte o que focamos como agência, o que é possibilitado pelo Headless é principalmente uma experiência coisa. Em termos do que seus usuários interagem. E muitas vezes, e essa é uma conversa que muda para todas as empresas. Algumas empresas só querem fazer o trabalho. Algumas empresas querem ser chamativas sobre isso.

E em todos os casos em que é importante para o cliente ter uma experiência realmente inovadora, ou algo realmente inovador em termos de desempenho, ou eles precisam de algo consideravelmente mais envolvente na competição, todas essas coisas são muito, muito mais fáceis fazer no Headless. E então a conversa em minha mente, ou pelo menos o ângulo do qual tendemos a começar, é apenas– é isso, você precisa fazer isso ou isso, você precisa fazer isso e impressionar muito as pessoas com isso.

Porque, obviamente, o WordPress já faz isso há muito tempo e é um lugar sólido para construir um site, mas basicamente, quanto “chamativo chamativo” você quer? E se você quer muito, então Headless é uma ótima maneira de

HASHIM WARREN: Isso é incrível. Jimmy, quero falar sobre pessoal em termos de agência. Quando você pensa em projetos Headless, você quer desenvolvedores WordPress que adotaram JavaScript e, digamos, algo como React? Ou você prefere ter um desenvolvedor JavaScript que nem usa WordPress? Por exemplo, como você pensa sobre a equipe quando se trata de projetos Headless WordPress?

JAMES SQUIRES: Sim, é uma boa pergunta. Em nossa agência, procuramos o React como uma espécie de linha de base principal, portanto, obviamente, JavaScript e experiência no framework React. Isso é meio que obrigatório, em todos os níveis, na verdade. O WordPress é – tratamos isso como um “bom ter”. Isso é algo, especialmente no espaço Headless, que podemos treinar relativamente rápido.

Quero dizer, de um modo geral, com o Headless, você gasta seu tempo no WordPress desenvolvendo tipos de postagem personalizados e apenas apresentando a estrutura de componentes do ponto de vista de back-end, mas não está tocando muito no legado, tipo de aspectos baseados em temas em uma arquitetura normal sem cabeça. Portanto, descobrimos que realmente não precisamos dessa experiência central do WordPress.

É claro que precisamos de alguns jogadores na equipe que tenham isso para certos aspectos, mas, de modo geral, temos sido muito bem-sucedidos em atrair, digamos, um engenheiro React, que nunca tocou no WordPress antes. Mostrando a eles como fazer alterações nos campos e eles estão funcionando. Eles já entendem o GraphQL, que é uma competência essencial com a qual você precisa se familiarizar para entrar em arquiteturas sem cabeça.

Mas, além disso, o conhecimento do WordPress pode ser bastante superficial e você pode contratar alguém e ser muito produtivo em um projeto. Essa é a beleza dos componentes do React: qualquer desenvolvedor do React pode pular no meio de um projeto, olhar para minha pasta de componentes e atribuir um a eles, e eles partirão para as corridas, desde que tenham sua estrutura de dados já definida.

HASHIM WARREN: Isso é muito interessante também, em termos de poder separar o trabalho. Você trabalha neste componente e pode trabalhar nele separadamente do projeto. Esse é um ótimo exemplo.

Jonathan, como você pensa sobre isso quando se trata de projetos Headless WordPress? Você prefere ter um desenvolvedor WordPress cujas habilidades – que adiciona React a isso, ou qualquer framework JavaScript em seu currículo? Ou um desenvolvedor de JavaScript que escala no WordPress, como você pensa sobre isso?

JONATHAN JETER: Então, como Jimmy disse, precisamos de ambos, mas vamos procurar mais agora do React, do View, dos desenvolvedores JavaScript de front-end. Bem, todos se autodenominam Full Stack agora, mas os desenvolvedores de JavaScript que serão capazes de entrar. Eu quero fazer. E uma vez que entramos nisso, estamos fazendo um projeto Headless, oh, não é tão ruim assim.

Porque eles não estão lidando com todo o trabalho do PHP e tudo mais. Mas, ao mesmo tempo, transferimos algumas de nossas pessoas de DevOps para lidar com o WordPress de back-end, então não precisamos necessariamente de um desenvolvedor de back-end para fazer isso, então funciona muito bem. Vá em frente.

JAMES SQUIRES: Eu ia acrescentar que, pelo menos pela nossa experiência, o número de engenheiros que você pode colocar em um projeto sem cabeça e ser produtivo tende a ser muito maior. Por exemplo, acabamos de lançar um Headless baseado em SvelteKit– acho que é o primeiro no Atlas– na semana passada. Ainda não recomendo o SvelteKit para os clientes, mas gostamos bastante.

Mas tínhamos um excesso de oito engenheiros simultaneamente, todos trabalhando em componentes e, com o desenvolvimento baseado em temas, tendemos a nos esforçar mais para conseguir muitos engenheiros e sermos produtivos. Só porque as coisas são um pouco mais monolíticas, em termos de quantas coisas você pode tocar ao mesmo tempo. Tenho certeza de que é possível e você pode coordená-lo, mas achamos muito mais fácil em arquiteturas sem cabeça.

HASHIM WARREN: A propósito, é uma bela vista. Eu vi o lançamento. É um belo local.

JAMES SQUIRES: Obrigado.

JONATHAN JETER: A outra coisa que eu diria também é que sei que estamos falando apenas sobre WordPress, certo, mas lidamos com projetos que não são WordPress também, certo. Portanto, esses desenvolvedores de JavaScript podem trabalhar em vários sistemas de back-end, ao contrário de se eu contratar um desenvolvedor .net, eles só trabalham, na maioria das vezes, só trabalham em .net, certo.

Portanto, temos as pessoas que garantem que as APIs funcionem, agregando os dados, reunindo todas essas coisas, certo. E então temos os front-ends que podem trabalhar em qualquer um desses projetos, em vez de serem específicos para um idioma específico.

TAYO ONABULE: E acho que há algumas coisas aqui que estamos mencionando. Eu acho, vamos dizer como é, como React, um– No nosso caso, tendemos a ficar com o React de qualquer maneira. Temos alguns desenvolvedores do View, mas tendemos a ficar com o React. Mas todas essas estruturas de front-end foram projetadas especificamente com o tipo de desenvolvedor e processo em mente. Eles são projetados - imagino que o Sr. Facebook em algum momento tenha pensado, vamos garantir que isso seja o mais eficiente possível para nossa equipe.

E assim, isso é fundamental para o que é React, e vai ser o mesmo para View e Angular. Em termos do lado do WordPress, mais uma vez, chame-o como é. Essencialmente, você poderia sobreviver apenas sabendo como navegar no back-end do WordPress e usar o ACF. E caso contrário não tem conhecimento de WordPress e ainda consegue construir um site WordPress Headless.

E assim o requisito do lado do WordPress, a menos que você esteja tentando fazer coisas que começam a ficar complicadas, você poderia tecnicamente construir um site Headless WordPress com basicamente conhecimento de onde está o arquivo .php de funções e nada mais. Você pode sobreviver. E acho que a beleza disso é, como Jonathan disse, mais uma vez, esses desenvolvedores de JavaScript serão úteis em todos os seus projetos. E acho que é bastante seguro dizer que, em um futuro previsível, a web será focada em JavaScript, e isso é um talento muito útil.

Quão longe da linha que o último interruptor, é provável que demore um pouco. Então, honestamente, não é realmente um grande compromisso de certa forma. É aquele que faz sentido que eu imagino na maioria dos casos.

HASHIM WARREN: Só quero confirmar sua história porque, em uma vida anterior, tive que treinar dois desenvolvedores React em nosso novo site WordPress. E era um site WordPress Headless. E foi apenas uma tarde. Mostrei a eles o ACF, eles ficaram muito empolgados, fizeram os modelos de dados e partiram. E até mesmo um dos desenvolvedores realmente conectou o editor clássico e fez com que eu pudesse controlar alguns componentes no front-end.

Isso foi antes do Gutenberg, então estávamos usando campos de repetição e ACF e controlando alguns dos componentes no front-end. Foi fantástico. Mas os dois desenvolvedores do React entenderam imediatamente. Eles levaram apenas a tarde e foram para as corridas.

TAYO ONABULE: O problema é que, com esse tipo de desenvolvedor de front-end, eles estão bastante acostumados a conectar-se a back-ends para obter seus dados e ter uma estrutura de dados para aderir. Esse é um componente comum de seu fluxo de trabalho, portanto, o WordPress não oferece muitas chances.

JONATHAN JETER: Com a prevalência de - desculpe, a prevalência de SaaS, aplicativos disponíveis em todos os lugares agora, coisas que você costumava fazer no WordPress, seja comércio eletrônico, seja integração com o CRM, todo esse tipo de coisa. Agora isso não é feito no – não precisa mais ser feito no WordPress. Você não precisa instalar um plug-in do Marketo ou um plug-in do Salesforce, ou algo assim para tentar conectá-los, certo.

Agora você mesmo está fazendo essas conexões, o que permite uma experiência melhor e personalizada. Isso permite velocidade, segurança, todas essas coisas, em vez de tentar colocar um desenvolvedor PHP lá para descobrir como fazer essas coisas funcionarem dentro do WordPress.

HASHIM WARREN: Incrível. Stephen, eu adoraria ouvir de você sobre o ecossistema, o ecossistema JavaScript. Eu sei que os desenvolvedores do WordPress estão acostumados a um ecossistema realmente impressionante e robusto, em termos de plugins, também comunidade. Você pode falar sobre como ele se compara talvez ao ecossistema no mundo do JavaScript? Tanto em termos de tecnologia quanto de comunidade.

STEPHEN BROOKS: Sim, com o WordPress, ele tem o maior mercado de plug-ins para a construção monolítica tradicional. Mas, voltando ao ponto de Jonathan há apenas um segundo, com o aproveitamento do NPM para todas as funcionalidades de que você precisa no front-end, é equivalente, se não maior, do que o WordPress marketplace. Porque você não só tem todos os pacotes NPM que estão disponíveis. Há também vários STKs que você também pode obter para criar rapidamente toda a integração de dados de que precisa.

Então eu quase diria que é maior em cerca de 20%. Apenas lançando um número arbitrário, mas é muito mais rápido para as pessoas se moverem. E muito do material do NPM está no ponto. Você também não precisa se preocupar com a versão principal do WP e as incompatibilidades de versão do plug-in que podem acontecer. Depois de fixar suas versões no manifesto do pacote, quero dizer que você está pronto. Você realmente não precisa mais se preocupar em atualizá-los se não quiser ou algo assim.

Então, novamente, voltamos ao que todo mundo está dizendo, velocidade e flexibilidade são primordiais sempre que usar a solução Headless em oposição à abordagem tradicional do WordPress.

JAMES SQUIRES: Sem querer jogar sombra nas empresas que estão ganhando muito dinheiro com seus plug-ins WordPress, mas essa é outra área, já que você tende a ter menos custos de licenciamento em uma arquitetura sem cabeça, enquanto em uma típica baseada em tema, há alguns plugins realmente ótimos por aí que sempre nos encontramos colocando em propostas para comprar e utilizar. Na maioria das vezes, tudo no NPM é software livre e de código aberto.

Certamente há alguns que podem ter um modelo de serviço associado a eles. Mas, de um modo geral, você pode encontrar a solução mais popular e sua licença de código aberto. Portanto, é fácil mover-se rapidamente dessa maneira e não retardá-lo com aprovações de clientes sobre custos de licenciamento e coisas assim.

HASHIM WARREN: Jimmy, tenho outro exemplo assim. Então, eu estava construindo um site Gatsby e adicionando o Google Analytics a ele. O Gatsby possui um ecossistema de plug-ins, todos os plug-ins são de código aberto. Seus pacotes estão no NPM, são fáceis de instalar. Então estou adicionando o Google Analytics, e ele tinha todas essas opções que, com o plug-in mais popular do Google Analytics para WordPress, algumas dessas opções vão para a versão premium. Por isso, fiquei muito empolgado como alguém que está feliz em pagar por este plug-in do WordPress para ter a mesma funcionalidade com este pacote que também era um plug-in do Gatsby. Muito animado sobre como esses ecossistemas combinam.

TAYO ONABULE: Eu acho que foi muito rápido em todo o assunto do NPM também. Eu acho que é apenas uma coisa mínima, e é provavelmente inconsequente, mas eu por mim. Eu prefiro muito mais o fato de que quando você está desenvolvendo algo no React, você quer algo, você baixa através do CLI. E você não precisa entrar no WordPress, ou qualquer tipo de pegajoso, está apenas lá no seu espaço. Você não precisa sair do estúdio e está tudo lá. E é um processo muito menos desajeitado do que fazer alguma pesquisa, encontrar um plug-in, instalá-lo etc. Nunca fui fã disso.

HASHIM WARREN: Incrível. Jonathan, quero perguntar a você, conversamos sobre os requisitos que fariam você dizer que isso é perfeito para o WordPress sem cabeça. Que tipo de projeto faria você sentir que é, OK, este deve ser um projeto WordPress tradicional.

JONATHAN JETER: Então, fazemos muitos desses também, certo. Às vezes é orçamento. Eles vêm e dizem, nós temos tanto. Nós pensamos, não há escolha, certo. Isso é o que estamos fazendo, certo. E porque, então temos coisas que usamos. Esse processo e esse sistema já estão em vigor. Como Jimmy estava dizendo, temos plug-ins que inserimos em cada uma dessas propostas porque sabemos que é muito direto.

Portanto, um site típico de marca pequena. Típico– Como Tayo estava dizendo antes, não precisa ser chamativo, certo. Não há nada escandalosamente criativo sobre este site, certo. E eles simplesmente disseram, ei, já os tivemos antes, como se soubéssemos que precisamos de um site, então faça-nos um. Certo. E se for esse o caso, sim, com certeza, com base no seu orçamento e nos requisitos, um site padrão do WordPress servirá.

Chegamos ao ponto em que, usando Genesis, Genesis Pro, Smart Plugin Manager e todos esses tipos de coisas, temos sites que construímos que os desenvolvedores nem tocam. Ele apenas passa pelo processo, e o processo criativo, o estúdio edita os arquivos e eles basicamente colocam o conteúdo. Temos alguns editores que provam e colocam o conteúdo, e o site é feito sem que um desenvolvedor toque isto.

E é assim que você tem que fazer, certo, para ganhar dinheiro com esses projetos, porque com esses tipos de orçamentos, você não consegue 20 horas de desenvolvimento no back-end de um desses sites. Normalmente é assim que decidimos, a menos que seja um site enorme, mas eles dizem não, não, não, não queremos nada sofisticado. Nós apenas queremos que este seja um site regular. Fizemos isso, muito conteúdo, blogs, esse tipo de coisa.

Em termos de SEO, o WordPress ainda é ótimo. Se é isso que eles estão procurando, é como se não nos importássemos com a aparência. Queremos apenas a função. Queremos que seja rápido. Queremos ter conteúdo e ranquear bem. Um site WordPress tradicional funciona bem.

HASHIM WARREN: Incrível. Stephen, can speak to that? 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.