DE{CODE}: Headless 101 para desenvolvedores WordPress

O desenvolvimento headless pode ser mais poderoso e ainda mais divertido do que o desenvolvimento tradicional do WordPress. No entanto, com tantas novas opções nessa pilha emergente, qual é a melhor maneira de começar? Este workshop orientará os construtores na instalação e otimização de um projeto WordPress para headless, até o modelo de sua primeira página em um front-end desacoplado.

Slides da Sessão

Transcrição de texto completo

GRACE ERIXON : Bem-vindo ao Headless 101 para desenvolvedores WordPress. Meu nome é Grace Erixon e sou uma defensora do desenvolvedor associado aqui no WP Engine. Juntando-se a mim está Steve da Haus. Hoje, daremos a você uma rápida introdução sobre o que é o WordPress sem cabeça e como você pode começar a usá-lo.

Portanto, para entender o que é uma arquitetura de site WordPress sem cabeça, é importante ter certeza de que estamos todos na mesma página sobre a aparência de uma arquitetura tradicional do WordPress. Tradicionalmente, um CMS como o WordPress lidaria com o front-end e o back-end de um site.

Em uma arquitetura tradicional, o editor cria e gerencia conteúdo como postagens de blog e páginas dentro do WordPress. O desenvolvedor escreve o código para controlar a aparência e o funcionamento do site usando PHP e a API de tema do WordPress. Em seguida, o WordPress gera a página HTML que é enviada ao visitante.

Nesta arquitetura CMS acoplada, o WordPress fornece os recursos de gerenciamento de conteúdo para os editores. E também é responsável por fornecer páginas HTML aos visitantes do site. Um CMS headless usa uma arquitetura desacoplada em que o front-end e o back-end são gerenciados separadamente. Em uma arquitetura headless, o editor ainda cria e gerencia o conteúdo no WordPress, da mesma forma que em uma arquitetura tradicional do WordPress.

O desenvolvedor escreve o código para controlar a aparência e o funcionamento do site em JavaScript, além de usar o WPGraphQL ou a API REST para extrair dados do WordPress. Uma estrutura como Faust.js, Next.js, Nuxt.js ou SvelteKit é frequentemente usada para alimentar esse aplicativo de front-end. Em seguida, o aplicativo JavaScript front-end gera e exibe as páginas HTML que são enviadas ao visitante do site.

Ao contrário de uma arquitetura tradicional, o WordPress não é mais responsável por gerar páginas HTML. Portanto, a interação para troca de conteúdo entre o back-end do WordPress e o front-end do aplicativo JavaScript ocorre por meio da camada da API. As duas opções para a camada de API são a API REST do WordPress ou WPGraphQL.

A API REST vem junto com o WordPress. No entanto, o padrão de acesso a dados que ele requer pode ser lento porque o REST requer que cada recurso tenha seu próprio terminal. Por exemplo, seriam necessárias várias viagens de ida e volta para reconstruir um poste totalmente modelado. Se você quiser obter o conteúdo, o autor e a categoria de uma postagem, serão necessárias três chamadas de API separadas.

Por outro lado, o WPGraphQL nos permite solicitar o conteúdo, o autor e a categoria de uma postagem em uma única solicitação. Por causa disso, WPGraphQL é nossa camada de API preferida. WPGraphQL é um plug-in gratuito que fornece um esquema GraphQL extensível e uma API para o seu site WordPress. O WPGraphQL é mais rápido que a API REST porque obtém os dados exatos solicitados e resulta em menos funções executadas por meio da otimização de consulta, menos download de dados, carregamento de dados mais eficiente e vários recursos sendo incluídos em uma única solicitação.

Uma arquitetura sem cabeça dá aos desenvolvedores a liberdade de escolher qualquer pilha de tecnologia de front-end, sendo as estruturas JavaScript as mais populares. Algumas das estruturas JavaScript de front-end mais populares incluem React, Vue.js e Svelte. Novos frameworks estão sendo lançados o tempo todo, então esta lista está longe de ser completa.

Muitos desses frameworks JavaScript são usados ​​em conjunto com metaframeworks que adicionam soluções para coisas como roteamento, renderização do lado do servidor e muito mais. React é usado em conjunto com Next.js, Vue.js é usado em conjunto com Nuxt.js e Svelte é usado em conjunto com SvelteKit. Gatsby é outro metaframework popular.

O WP Engine desenvolveu o Faust.js, uma estrutura JavaScript construída sobre React e Next.js. O Faust foi criado especificamente para oferecer suporte a aplicativos da Web sem cabeça do WordPress. Ele suporta autenticação e visualizações de postagem prontas para uso, fornece ganchos React integrados convenientes para acessar dados do WordPress e muito mais.

Então, falamos sobre o que significa uma arquitetura headless do WordPress e os tipos de tecnologia que você usaria. Mas vamos falar rapidamente sobre por que você escolheria o headless. O próprio WordPress é um CMS pesado e usa PHP, que não é uma linguagem rápida. O Headless WordPress usa linguagens adotivas por meio de JavaScript e carrega apenas os arquivos necessários por meio de chamadas de API. É muito mais leve, então seu site carregará mais rápido.

O Headless WordPress também minimiza o risco para o seu conteúdo, pois seus dados vivem separados de sua entrega de front-end. Está menos exposto a ataques da web. E o principal benefício é que a arquitetura headless do WordPress permite que os editores continuem a se beneficiar da excelente experiência de publicação que o WordPress oferece, além de permitir que desenvolvedores e visitantes do site aproveitem os recursos técnicos que os aplicativos JavaScript modernos trazem para a mesa.

Agora, vamos nos aprofundar no código de um site headless real. Eu pré-gravei um passo a passo do novo site WordPress headless do Atlas Blueprints. O novo recurso Blueprints no Atlas fornece uma maneira realmente fácil de colocar um site WordPress headless completo em funcionamento. Eles vêm com código inicial, plug-ins, modelos de conteúdo e estrutura de página para fazer seu aplicativo decolar mais rapidamente.

Então, vamos criar um novo site do Blueprint para que possamos mergulhar no código. De dentro do painel do WP Engine, iremos para o Atlas. Clique em Criar aplicativo. Selecione Iniciar com Blueprint. E então vamos selecionar qual blueprint queremos usar. Vou escolher a planta do portfólio.

Em seguida, você conectará sua conta do WP Engine à sua conta do GitHub e clonará esse projeto em um novo repositório. Isso levará alguns segundos para ser construído. Por fim, você apenas selecionará o nome do repositório que acabou de criar, a região mais próxima de sua localização e, em seguida, clicará em Create App.

Agora, se você clicar no URL do Atlas, podemos verificar como é o nosso site WordPress sem cabeçalho. Estamos interessados ​​especificamente na página Postagens. Como você pode ver, o site está trazendo todas as postagens mais recentes para esta página Nosso Blog. E cada postagem também tem sua própria página de exibição individual. Mas de onde vêm todos esses dados?

Se voltarmos ao painel do WP Engine, veremos um botão para WP Admin. Aqui está o back-end do nosso site WordPress sem cabeça. Se eu clicar em Posts, você verá a mesma lista que o aplicativo da web estava acessando. Agora, podemos abrir o repositório GitHub no qual nosso Blueprint foi clonado. E vamos clonar esse repositório para nosso ambiente local.

Em seguida, abrirei este repositório no Visual Studio Code, meu editor de código favorito. Pesquisando no diretório do projeto, o arquivo para a página do blog pode ser encontrado em SRC, pages, posts, Index.js. Este projeto é construído usando React, Next.js, Faust.js e WPGraphQL. Se você não estiver familiarizado com o React ou mesmo com o JavaScript, isso pode parecer confuso no início.

Na primeira seção, o arquivo está apenas importando coisas de que precisa de fontes internas e externas. A segunda seção que define os campos de pré-passagem dos pós-nós é onde todos os dados de que precisamos são listados. Executar isso por meio do prepass garante que os dados estejam lá quando precisarmos deles e que nenhuma solicitação em cascata ocorra.

Então temos a função de página. A princípio, é apenas coletar os dados de que precisamos em algumas variáveis ​​diferentes, ou seja, as configurações gerais e uma lista paginada de postagens. As tags dentro da instrução de retorno são o código que será renderizado visualmente na página da web. Primeiro, temos o componente para o cabeçalho. Então, dentro deste componente principal, temos um componente de cabeçalho de entrada, e é isso que exibe o grande título que diz Postagens mais recentes no topo da página.

Por fim, chegamos ao componente post, que aceita a lista paginada de posts como parâmetro. Vejamos o que o componente post faz com essas informações. Aqui ele está percorrendo cada postagem contida na lista de postagens recebidas. Para cada postagem, ele exibe a visualização em forma de cartão na página da postagem mais recente. O primeiro consiste em um componente de imagem em destaque agrupado em um link para a página da postagem do blog individual, um título do título da postagem e um componente de informações da postagem que consiste na data e no autor da postagem.

De volta ao arquivo Index.js que exibe todas as postagens, terminamos exibindo o componente Carregar mais na parte inferior da página para recuperar mais postagens, se solicitado, e um rodapé. A última função, getStaticProps, é uma função de geração de site estático do Next.js que informa para pré-renderizar esta página no momento da compilação usando as props retornadas pela função. E é isso.

Obrigado ao Blueprints por lidar com a configuração do Headless para nós. Foi simples dividir o que entra na página de postagem para obter dados do back-end do WordPress usando WPGraphQL e exibir as postagens usando componentes React. Obrigado por sintonizar. Você pode me encontrar no Twitter @graceerixon.

Confira developers.wpengine.com para mais conteúdo sobre o Headless WordPress. Temos um tutorial sobre como criar seu primeiro site Headless WordPress do zero usando Faust.js e estamos trabalhando em uma série de conteúdo Headless 101 no momento. Você pode obter todas as ferramentas que o Atlas oferece se você se inscrever para uma conta gratuita do Sandbox. Agora vou passar para Steve para falar mais sobre porque a Haus escolheu o Headless WordPress para seu projeto leoburnett.com.

STEVE SCAVO: Obrigado, Grace. Olá, sou Steve Scavo, CTO da Haus. Somos um estúdio e agência de tecnologia criativa em Los Angeles, Califórnia. Esta palestra é apropriadamente intitulada Headless 101 para desenvolvedores WordPress. E, para ser sincero, não sou um desenvolvedor WordPress profissional, mas acho que isso faz parte da beleza de uma arquitetura sem cabeça.

Portanto, poderíamos facilmente ter chamado isso de Headless 101 para desenvolvedores não-WordPress que precisam aproveitar o WordPress. Esse poderia ter sido um título igualmente adequado. Isso é o que é bonito sobre sem cabeça. É uma vitória de todos os lados, como você verá.

Então, por que sem cabeça? Existem tantos motivos de alto nível sobre os quais poderíamos falar, mas acho que falar sobre exemplos reais de produção e exemplos do mundo real de quando brilha é realmente útil. E gostaria de mostrar um projeto que fizemos para Leo Burnett usando arquitetura sem cabeça sob uma arquitetura sem cabeça. Para contextualizar, a Leo Burnett é uma agência de publicidade de Chicago, mas eles têm muitos escritórios em todo o mundo. Então eles têm muito conteúdo, muito trabalho.

O site antigo estava operando em um único tema WordPress. Foi muito fragmentado, meio lento, não teve um bom desempenho. Era difícil de atualizar e não exibia o tipo de prestígio e marca que Leo Burnett queria transmitir. Então foi com isso que trabalhamos do ponto de vista do design. E escolhemos o headless para realmente modernizar sua pilha.

Nós apenas queríamos que ele parecesse vivo e fresco e tivesse aquele tipo de capacidade que precisamos ter para realmente criar uma experiência de usuário e interface do usuário maravilhosas. Queríamos aumentar seu poder editorial. Queríamos aumentar a cadência com que eles podem publicar conteúdo. Queríamos restabelecer a identidade da marca e ter uma interface do usuário e uma interação, a sensação do site que realmente exalava Leo Burnett e todos esses pequenos toques e pontos editoriais, tipográficos e de interação que eles queriam transmitir.

E queríamos preparar a base de código e o site para o futuro. Não queríamos apenas que o site fosse relevante pelos próximos 12 meses. Queremos que seja relevante para a próxima década, talvez. E eu acho que essa arquitetura sem cabeça, essa pilha sem cabeça realmente faz isso.

Portanto, um dos problemas iniciais do headless é que sempre há muitas decisões sobre hospedagem, implantação e infraestrutura, e sempre foi um grande ponto problemático. Portanto, essas decisões de pilha sempre foram deixadas para o desenvolvedor. E você procura e tem ideias, OK, qual aplicativo de terceiros, talvez CI/CD, você precisa usar? Vamos hospedar isso na AWS? Como fazemos isso? Quais serviços? E então você meio que implementa esse tipo de solução potencial - essas soluções ad hoc em torno desse fluxo.

Bem, a plataforma Atlas e WordPress Engine Atlas realmente resolve isso. É aqui que entra em jogo. Escolhemos a Atlas por todos esses motivos, e eles têm essa infraestrutura de serviço gerenciado. Eles padronizam o pipeline de CI/CD. Você realmente não tem que pensar sobre isso.

Há migrações de dados entre os ambientes que são essencialmente reduzidas a um fluxo de um clique. Historicamente, esse sempre foi um grande problema ao passar do controle de qualidade para o estágio e para a produção. Essencialmente, o WordPress Engine e a plataforma Atlas reduziram isso a um único clique.

E há apenas esse cansaço em torno de microsserviços e DevOps. Há apenas uma carga cognitiva pesada de quanto você tem que pensar e apoiar e estar ciente disso como desenvolvedor e mantê-lo funcionando. Essas são todas as coisas que a plataforma Atlas realmente tira de suas mãos e resolve de maneira benéfica.

Então, vamos falar sobre algumas das dinâmicas que eu acho que o headless realmente promove e realmente enfatiza. O primeiro pilar aqui - há três deles. O primeiro pilar é a experiência do desenvolvedor. Isso nos permite escolher a ferramenta certa para o trabalho. E quando digo nós, quero dizer desenvolvedores.

Ele nos permite escolher uma pilha na qual queremos escrever o código. E isso é, para nós, na Haus, isso é Next.js e React. Next.js é apenas uma estrutura maravilhosa em torno de algumas convenções muito boas para roteamento, desempenho e arquitetura de aplicativos. E também queríamos implementar um sistema de design, e não apenas um sistema de design visual, mas um sistema de design codificado. Isso é algo que mantém nosso aplicativo consistente, testado e bonito.

As interações são consistentes. Isso nos permite criar novas páginas e recursos nesse ecossistema daqui para frente também, e manter isso e manter essa consistência. Ele também nos permite escrever código expressivo declarativo e o React o endossa como uma biblioteca. Mas também acreditamos nesse estilo de escrever em equipe. Ele nos permite escolher essa pilha para nós no front-end, enquanto talvez um site WordPress baseado em tema tradicional não tenhamos o mesmo luxo.

Também precisamos de muito espaço criativo. Você pode ver quando visitar leoburnett.com, há belas transições de página. Existem – não estamos presos à pilha tradicional do WordPress sobre como as coisas devem ser renderizadas. O WordPress não é mais responsável por renderizar o frontend.

Nosso headroom é virtualmente ilimitado. Podemos escolher nossas bibliotecas de animação. Podemos escolher a maneira como nossos componentes interagem uns com os outros. É um grande benefício do lado DX.

A experiência do administrador é elevada e acho que otimizamos isso porque nunca nos afastamos de sua antiga familiaridade. Não há corte de back-end. Nós fomos de WordPress para WordPress. Não precisávamos exportar dados e escrever scripts para mudar para outro sistema proprietário. Então a familiaridade é enorme. Queríamos manter esse tipo de fluxo para os administradores atuais do leoburnett.com.

Adoção e documentação – se você passar cinco minutos na web, provavelmente já tocou em um back-end do WordPress, e isso simplesmente não pode ser exagerado. Leo Burnett também tem muitos pontos de conteúdo muito específicos e campos personalizados. O WordPress oferece isso e dá a você esse poder, mas conseguimos implementar o plug-in Advanced Custom Fields, que é uma convenção muito boa para ajustar a interface do usuário do administrador para torná-la realmente amigável e utilizável. Portanto, foi uma vitória na experiência administrativa.

Agora, claro que o terceiro pilar é a experiência do usuário. É o que realmente importa. Usuários, acho que da mesma forma que acreditamos que os aplicativos da Web na Haus devem parecer aplicativos nativos, não deve haver desistência. Acho que os usuários realmente apreciam isso também.

Eles são perfeitos. Eles são responsivos. Eles apenas se sentem bem. E acho que queríamos que Leo Burnett e todos os nossos aplicativos se sentissem assim. Ser capaz de escolher a pilha que queremos no front-end nos permite fazer isso.

Os aplicativos nativos são inerentemente desacoplados de suas infraestruturas de conteúdo de back-end, assim como nossos aplicativos da web. E é isso que a Atlas promove. Isso é o que a arquitetura headless em geral promove. Também promove o desempenho. Podemos renderizar universalmente nossa IU. Isso significa que a carga inicial está no lado do servidor. E depois disso, o cliente assume.

Há muitos benefícios aqui. Uma delas é que isso deixa os mecanismos de busca felizes. Eles são conteúdo do lado do servidor. É rápido. Ele também nos permite pré-renderizar praticamente instantaneamente a próxima página e fazer essas solicitações com base no que está na janela de visualização uma única vez.

Para Leo Burnett, em termos da API de conteúdo que escolhemos consumir, configuramos um endpoint GraphQL. Isso significa que há cargas úteis mais enxutas voltando. Estamos definindo explicitamente exatamente o conteúdo de que precisamos. Há menos hidratação após a renderização do lado do servidor na renderização do lado do cliente.

Isso significa menos código passando pela rede, menos resposta, tempos de resposta mais rápidos. É definitivamente uma vitória, e eu sugiro que, se você for mudar para um fluxo de trabalho do Atlas ou um fluxo de trabalho sem comando, dê uma boa olhada no uso da API GraphQL em vez de talvez algo como uma API REST.

E do ponto de vista do usuário, eles estão vendo conteúdo novo e oportuno. Este é um fluxo de publicação otimizado para visualização de conteúdo. Ele é otimizado para buscas rápidas de conteúdo no lado da preparação e das visualizações e, em seguida, promove isso na produção. Os administradores da Leo Burnett estão extremamente satisfeitos com a facilidade de atualizar o conteúdo e isso deixa os usuários felizes.

Qual é o resultado? Isso é meio que enrolar tudo. É desenvolvedores inspirados, administradores produtivos e usuários felizes. Esta é a tríade e a esperança pela qual todas as equipes de desenvolvimento da web realmente se esforçam.

Quando os desenvolvedores estão inspirados, eles estão usando um conjunto otimizado de ferramentas. É uma sensação boa. Eles estão felizes. Eles escrevem códigos melhores.

Os administradores sabem que estão produzindo conteúdo em um belo ecossistema. É rápido. Ele envia rapidamente. E os usuários estão vendo esse conteúdo atualizado e experimentando um front-end moderno, bonito, funcional e otimizado.

Acho que para encerrar - apenas alguns pensamentos finais que eu adoraria que você tivesse em mente. Acho que o brief, por si só, sempre tem uma linguagem ausente. Acho que muitas vezes falamos apenas sobre, ei, construa-me um belo site. Construa-me um site incrível. Eu quero que pareça - e fizemos todas essas análises com os clientes.

E todo mundo fica animado, e então o V1 vem e é lançado. E então as pessoas que precisam assumir o controle daquele site ficam tipo, você me deu uma bagunça. Como faço para cuidar disso? Isso é algum fluxo ad hoc que você concebeu?

Você não quer construir um belo site e entregar um fardo. Temos muito orgulho aqui na Haus de não fazer isso. E acho que o que é maravilhoso no Atlas e no Atlas como plataforma é que ele resolve isso.

Isso lhe dá a confiança de que você está enviando um ecossistema e um sistema de publicação na Web que realmente faz sentido do ponto de vista da infraestrutura e da implantação do código. Ele fornece prova documentada para a equipe de TI e a equipe de engenharia ou a equipe de marketing de que você sabe o que está fazendo e que eles estão em boas mãos agora com este novo site que você criou para eles.

Porque lembre-se, não estamos apenas construindo um site. Estamos estabelecendo um sistema de publicação de conteúdo, e isso é fundamental para entender e reconhecer desde o primeiro dia. E, novamente, é aqui que o Atlas entra em jogo.

Portanto, espero que esse pequeno detalhe ajude você a conceber estrategicamente sua pilha sem cabeça daqui para frente. Se essa é a direção que você deseja seguir, recomendo fortemente que você dê uma olhada no Atlas. Espero que tenham gostado da sessão, e muito obrigado.