Quando e quando não usar o WordPress sem cabeça

O Headless WordPress vem ganhando cada vez mais interesse de desenvolvedores e empresas de hospedagem, especialmente nos últimos meses. Com o WP Engine lançando sua hospedagem Atlas e mais e mais desenvolvedores preferindo estruturas Javascript para alimentar o frontend de seus sites, o WordPress sem cabeça parece oferecer o melhor dos dois mundos: uma experiência editorial familiar no backend com a flexibilidade de escolher uma pilha de tecnologia moderna no front-end.

No entanto, para todos os benefícios do WordPress sem cabeça, definitivamente existem algumas desvantagens também. Nem todo ambiente de hospedagem está configurado para lidar com o WordPress headless nativamente, portanto, se você estiver acostumado a uma configuração mais tradicional do WordPress, talvez seja necessário ser criativo com sua hospedagem.

Além disso, como o frontend e o backend são separados, algumas das partes do WordPress que normalmente são incluídas precisam ser recriadas ou pelo menos reimaginadas.

Neste artigo, veremos alguns dos casos de uso em que o WordPress headless realmente brilha, bem como algumas das situações em que você pode querer manter uma configuração mais tradicional do WordPress. E, no final, espero dar a você uma ideia melhor sobre se o WordPress headless é uma boa opção para o seu próximo projeto. Vamos mergulhar.

O que é WordPress sem Cabeça

Enquanto uma configuração tradicional do WordPress é executada em um servidor que fornece o back-end para editores e criadores de conteúdo, além de fornecer o modelo e tudo mais para tornar o site com boa aparência no front-end, o WordPress sem cabeça é um termo usado para descrever quando o front-end e o backend que compõe um site WordPress são separados.

Isso significa que, embora a experiência de back-end tradicional do WordPress seja a mesma, o WordPress não é responsável por fornecer nenhum modelo ou conteúdo relacionado ao tema.

Em uma configuração headless, o WordPress gera todo o conteúdo do site por meio de endpoints da API (geralmente a API REST do WordPress ou o WP GraphQL). Esses endpoints de API são consumidos por um frontend separado que é inteiramente responsável por lidar com a exibição do conteúdo.

Em muitos casos, este é um site combinado com uma das estruturas Javascript populares, um aplicativo móvel, um aplicativo de conversação desenvolvido por Alexa ou Google Home ou quase qualquer interface que possa consumir conteúdo via API. Dê uma olhada no vídeo do WPCasts abaixo para ver como isso pode ser.

Isso torna um site WordPress sem cabeça muito mais flexível em termos de como o conteúdo pode ser apresentado. Com uma configuração tradicional do WordPress, você fica em grande parte bloqueado na saída controlada pelo tema, mas com o headless, você pode produzir o mesmo conteúdo e apresentá-lo aos seus usuários finais de muitas maneiras diferentes, porque a apresentação é controlada pela plataforma que em última análise, consome os endpoints da API.

Benefícios do WordPress sem Cabeça

O WordPress sem cabeça continua a crescer em popularidade porque, para algumas equipes de desenvolvedores e de conteúdo, definitivamente há alguns benefícios fortes em uma configuração sem cabeça.

Diferentes equipes podem fazer o que fazem melhor

Algumas organizações, mesmo empresas de software que empregam desenvolvedores, descobrem que, embora o departamento de marketing queira usar o WordPress para o site de marketing, isso não se sobrepõe ao conjunto de habilidades de seus desenvolvedores existentes e acabam terceirizando esse trabalho para uma agência ou um freelancer. quem é mais centrado no WordPress.

No entanto, com uma configuração headless do WordPress, os desenvolvedores internos podem optar por usar qualquer estrutura de frontend que desejarem para desenvolver o frontend do site, aproveitando suas habilidades existentes, mesmo que não tenham experiência com o WordPress.

O trabalho específico do WordPress pode ser terceirizado e conectado com o frontend interno via API, potencialmente economizando custos para desenvolver o site, além de permitir que todo o conhecimento específico da marca e da empresa interno seja transmitido no frontend do site onde pode haver algo perdido na tradução de outra forma.

Editorial pode usar o WordPress com o qual está familiarizado

Se você tem uma equipe editorial ou criadores de conteúdo que já estão familiarizados com a experiência de edição do WordPress (que é cada vez mais comum à medida que o WordPress conquista ainda mais participação de mercado), você não precisa decidir entre deixar seu frontend atualizado com as tecnologias mais recentes e dando à equipe de criação de conteúdo uma experiência familiar.

Ao usar uma configuração do WordPress sem cabeça, os criadores de conteúdo podem continuar a produzir conteúdo na experiência do WordPress com a qual estão familiarizados, enquanto a equipe de desenvolvimento é livre para usar qualquer tecnologia de front-end com a qual se sinta mais confortável.

As APIs de back-end podem alimentar diferentes plataformas

Ao trabalhar com uma configuração headless em que o WordPress está alimentando endpoints de API em vez de simplesmente fornecer modelos de front-end, você tem a flexibilidade de fazer com que esses endpoints enviem conteúdo para interfaces que não sejam apenas um site.

Os mesmos endpoints de API que enviam seu conteúdo para a web também podem alimentar aplicativos móveis, fazer interface com outro CMS que alimenta uma publicação impressa, ser o provedor de conteúdo para um aplicativo de voz com Alexa ou Google Home e muito mais.

Como muitas interfaces são configuradas para consumir APIs, usar o WordPress como um aplicativo headless realmente amplia as possibilidades de onde você pode usar e reutilizar o conteúdo que já está escrevendo no WordPress.

Desvantagens do WordPress sem Cabeça

Embora existam alguns benefícios para uma configuração sem cabeça do WordPress, definitivamente não é para todos. Se você está acostumado a uma experiência mais tradicional do WordPress e não se encaixa em nenhuma das situações acima, aqui estão algumas das possíveis desvantagens que você deve considerar antes de entrar.

Plugins nem sempre funcionam

A maioria das pessoas tem a impressão do WordPress e do ecossistema WordPress de que, se você precisar de funcionalidades adicionais para o seu site, pode procurar um plugin que forneça essa funcionalidade, instalá-lo e “simplesmente funciona”, muitas vezes sem nenhum código ou configuração necessária.

No entanto, com uma configuração do WordPress sem cabeça, muitos plugins não funcionam imediatamente, pois não estão necessariamente cientes de que precisam fornecer sua funcionalidade via API. Para alguns plugins, esse tipo de comportamento nem é possível.

Veja, por exemplo, um plug-in que adiciona links de compartilhamento social ao topo da página de postagem única para tornar o conteúdo mais facilmente compartilhável em várias redes sociais. Com uma instalação normal do WordPress, este plugin pode ser ativado e os ícones de compartilhamento social podem ser facilmente injetados automaticamente ou usando um shortcode ou algo assim e você estará pronto.

No entanto, com uma configuração headless, esses ícones sociais não são transmitidos pela saída da API, porque eles não existem no conteúdo da postagem. E mesmo que eles fossem de alguma forma adicionados à saída do endpoint da API para uma postagem específica, eles não apareceriam no frontend do site, a menos que o frontend fosse criado especificamente para procurar essa saída e exibir os botões. Embora não seja impossível, isso torna muitos plugins do WordPress mais demorados para implementar em uma configuração headless.

Equipes familiarizadas com o WordPress nem sempre “ficam” sem cabeça

Se seus desenvolvedores ou equipe de desenvolvimento já estão familiarizados com uma configuração mais tradicional do WordPress, onde existe lógica de exibição no tema e a maioria das personalizações são feitas em arquivos de tema, mudar essa mentalidade para trabalhar com uma configuração sem cabeça às vezes pode ser difícil.

Mesmo do ponto de vista do processo de desenvolvimento, uma configuração headless às ​​vezes requer uma mudança na forma como o controle de versão é usado, como as implantações automatizadas e a hospedagem são configuradas e tratadas e aumenta a necessidade de comunicação, especialmente se dois desenvolvedores ou equipes diferentes estiverem trabalhando no partes de front-end e back-end do site. Todas essas coisas são tarefas com as quais os desenvolvedores costumavam trabalhar juntos em um tema WordPress mais padrão e podem nunca ter lidado antes.

A depuração pode se tornar mais difícil

Qualquer sistema, seja ele distribuído ou mais monolítico, pode ter bugs que surgem no decorrer da operação. Um dos desafios dos sistemas distribuídos, no entanto, é que há muito mais dados e muito mais escolhas que você precisa fazer ao tentar depurar um problema. Por exemplo, com uma configuração do WordPress sem cabeça, se você tiver um problema com as postagens que não carregam na ordem esperada.

Para começar a depurar esse problema, primeiro você precisa decidir se o problema era com a parte de front-end do site ou com o back-end. Como eles provavelmente estão hospedados em dois locais separados, você precisaria encontrar o arquivo de log correto para o sistema em que achava que o bug estava se originando.

Se houvesse um problema no back-end, por exemplo, onde não estava fornecendo as postagens corretas por meio do endpoint da API. Se você estava depurando um site WordPress normal, você pode tentar echo ou var_dump algumas informações de depuração e, em seguida, ver como essas informações são exibidas no front-end enquanto você depura.

No entanto, com uma configuração headless, essas informações não aparecerão em seu modelo, mas sim em seus endpoints de API. E dependendo de como seus endpoints de API estão configurados, esse tipo de depuração pode não funcionar.

Especialmente se o trabalho de manter o front-end do site e o back-end do site for dividido entre duas equipes diferentes, depurar uma configuração do WordPress sem cabeça é geralmente mais difícil e envolve mais comunicação do que um site WordPress mais tradicional. Especialmente se você não tiver tanta experiência com depuração de sistemas distribuídos, isso pode ser um bom motivo para preferir uma configuração mais direta.

WYSIWYG é mais difícil

Uma das principais promessas do Block Editor no WordPress é que ele aproxima sua experiência do WordPress muito mais perto de um dos ideais de muitas plataformas CMS – fornecendo uma experiência “O que você vê é o que você obtém” à medida que o conteúdo passa do editor para o front-end do site.

No entanto, em sites WordPress onde o estilo de bloco no editor está em uma base de código separada da exibição do front-end, acaba sendo um pouco mais difícil manter esses componentes em sincronia. Quando quaisquer alterações são feitas na base de código do frontend, essas alterações também precisam ser comunicadas e refletidas nos estilos do editor para manter essa experiência WYSIWYG consistente.

Tal como acontece com algumas das nossas outras desvantagens do WordPress sem cabeça mencionadas acima, isso significa apenas que mais comunicação e organização são necessárias para manter as duas bases de código sincronizadas e fornecer a melhor experiência para os criadores de conteúdo que usam o back-end, mas também para os usuários finais que experimentam o front-end do site.

Então qual é melhor?

Se você chegou até aqui, provavelmente pode antecipar essa resposta, mas se você deve ou não usar o WordPress sem cabeça para o seu próximo projeto de site realmente depende de você, da equipe que está trabalhando nele, de como o projeto é implantado e de muitos outros fatores.

Se você tem uma equipe de front-end forte que se sente à vontade para interagir com APIs e está acostumada a comunicar mudanças e trabalhar com sistemas mais distribuídos, pode fazer sentido que eles se concentrem no front-end do site enquanto uma equipe separada trabalha na parte real do WordPress .

No entanto, se você é mais um freelancer solo ou não tem muita experiência em sistemas mais distribuídos, controle de versão, implantação, etc, pode fazer sentido ficar com uma configuração mais tradicional do WordPress.

O WordPress sem cabeça pode ser um paradigma poderoso que permite alavancar tecnologias modernas e preencher a lacuna entre uma experiência editorial com a qual os criadores de conteúdo estão familiarizados, enquanto ainda pode usar algumas tecnologias mais recentes que ainda não chegaram ao ecossistema WordPress.

E como as ferramentas do desenvolvedor em torno do WordPress headless continuam a melhorar com hospedagem específica para headless e outras ferramentas projetadas para facilitar o desenvolvimento em uma configuração headless, ele só se tornará mais acessível para mais desenvolvedores e marcas.

Em suma, o WordPress sem cabeça está aqui para ficar e, se usado corretamente, pode ser uma ótima ferramenta em sua caixa de ferramentas à medida que você cria seu próximo site WordPress.