CMS sem cabeça: Gatsby JS com WordPress

É do conhecimento geral que o WordPress cobre cerca de um terço dos 1 milhão de principais sites do mundo, com mais de 50% de participação de mercado em sistemas de gerenciamento de conteúdo. Ainda em 2016, o WordPress decidiu introduzir uma API REST para fornecer a outros aplicativos acesso aprimorado ao conteúdo no banco de dados do WordPress. Resultantly, fornecendo aos desenvolvedores a capacidade de alavancar o WordPress como um CMS headless.

Isso inevitavelmente implicava que os engenheiros não estariam mais limitados a empregar a camada de apresentação convencional do WordPress (frontend), mas agora poderiam explorar qualquer aplicativo frontend para entregar seus dados. À luz disso, a maior parte deste blog irá explorar a relação do WordPress e Gatsby.js em relação à efetivação do CMS Headless.

Uma breve história do CMS

À medida que damos um passo atrás para entender a revolução do Headless CMS, acho que vale a pena recapitular a história dos sistemas de gerenciamento de conteúdo (CMS). Tradicionalmente, no início dos anos 90, as páginas estáticas eram a principal maneira de executar sites onde um webmaster editava diretamente arquivos HTML e os enviava para um servidor via FTP. Eventualmente, em meados dos anos 90, a tecnologia da web começou a evoluir e o conteúdo tornou-se mais dinâmico, levando ao surgimento dos primeiros sistemas monolíticos de gerenciamento de conteúdo.

Essencialmente, um CMS monolítico é um aplicativo de software que inclui tudo o que é necessário para editar e publicar conteúdo na web. O primeiro desses sistemas estava limitado a empresas como EpiServer, no entanto, variações posteriores de código aberto apareceram como WordPress, Drupal e Joomla. O resto é história, pois o WordPress ganhou a maior participação de mercado ao longo do tempo.

No entanto, mais tarde, durante a revolução dos smartphones, os dispositivos móveis começaram a afetar a forma como o conteúdo da web era consumido e entregue. Esse foi um desafio para os CMSs monolíticos tradicionais projetados para fornecer conteúdo da Web para laptops e desktops.

Para mitigar isso, nasceu o design responsivo que resultou em layouts de sites adaptáveis ​​ao tamanho da tela. Consequentemente, isso também proporcionou uma oportunidade de desacoplar o gerenciamento de conteúdo da camada de exibição. É aí que entram nossos CMSs Headless.

CMSs sem cabeça

Como mencionado anteriormente, um CMS Headless é aquele sem uma camada de apresentação. Como resultado, o conteúdo é entregue por meio de uma API (RESTful ou GraphQL) para separar o aplicativo front-end que o apresenta. A API disponibiliza conteúdo para qualquer canal e dispositivo usando uma variedade de ferramentas e linguagens de programação com maior nível de segurança e escalabilidade.

Essencialmente, o CMS é dissociado das preocupações de front-end, o que, por sua vez, libera os desenvolvedores para criar experiências ricas para os usuários finais, usando a melhor tecnologia disponível. Um modo “headless” ou “desacoplado” é atualmente suportado pela maioria dos CMSs, o que abriu o caminho para os sites Gatsby.

Portanto, para aproveitar um CMS headless, você terá que criar seu site ou aplicativo primeiro e, em seguida, usar a API do CMS para conectar seu conteúdo.

A execução do WordPress Headless CMS

Em relação à cronologia de eventos compartilhada acima, vimos como o WordPress acabou efetivando um CMS Headless. WordPress Contém uma API (Application Programming Interface) que permite estendê-la com plugins (essencialmente como uma 'estrutura de aplicativos'). Em particular, isso é feito por meio da API REST, como veremos mais adiante.

No entanto, um dos principais conceitos da API do WordPress são os ganchos. Basicamente, os ganchos permitem que os plugins alterem a funcionalidade principal do WordPress. Praticamente, Hooks funcionam de forma que quando um determinado evento no WordPress ocorre (por exemplo, carregamento de página ou pós-edição), o WordPress chama um determinado hook para executar a função.

Especificamente, os ganchos são divididos em 'Ações' e 'Filtros'. As ações podem ser aproveitadas para executar certas funções PHP em determinados eventos, embora as funções não precisem retornar nada. Enquanto os Filtros podem ser utilizados para executar funções pelas quais o WordPress passa dados durante certos eventos com essas funções recebendo dados como um parâmetro e retornando uma versão modificada dos dados.

WordPress e a API REST

A transferência de estado representacional (REST) ​​é baseada no protocolo HTTP e fornece semântica de interface uniforme para criar, ler, atualizar e excluir dados (CRUD).

Geralmente, a execução da API REST no WordPress permite que os desenvolvedores acessem dados em um banco de dados WordPress remotamente enviando e recebendo objetos JSON (JavaScript Object Notation). Consequentemente, isso oferece aos desenvolvedores a oportunidade de criar, ler, atualizar e excluir dados do WordPress de outros aplicativos que não são projetados com o WordPress. Por exemplo, aplicativos da Web JavaScript ou aplicativos móveis nativos.

No entanto, à medida que nos aprofundamos no entendimento do relacionamento do Headless WordPress CMS com APIs REST e Gatsby, precisaremos observar alguns conceitos fundamentais da API do WordPress:

• Rotas e endpoints: Rotas são caminhos que você pode acessar via chamada HTTP, enquanto um endpoint é um método HTTP (como get, post, put ou delete) mapeado para essa rota.
• Solicitação: Quando você inicia uma solicitação HTTP para uma rota REST registrada, o WordPress cria automaticamente um objeto de solicitação. Os dados especificados na solicitação determinarão qual resposta você receberá.
• Resposta: Um objeto de resposta são dados que você recebe de volta quando faz uma solicitação. Pode incluir dados solicitados ou mensagens de erro.
• Esquema: Um esquema refere-se à estrutura de dados no terminal. Cada endpoint pode ter uma estrutura de dados ligeiramente ou significativamente diferente que pode retornar. Assim, um esquema determinará todas as propriedades possíveis que um endpoint pode retornar e todos os parâmetros possíveis que ele pode receber.
• Classes de controlador: as classes de controlador permitem que os desenvolvedores gerenciem e registrem endpoints e rotas, além de permitir que eles lidem com solicitações, utilizem esquemas e gerem respostas.

A 'estrutura' do React

À medida que agora entramos na carne do relacionamento Gatsby.js e WordPress, para mais contexto, temos que decifrar esse cenário tecnológico a partir de fundamentos mais históricos. React é a chave para esta história, pois é a biblioteca/framework de front-end JavaScript que mais cresce. Tornados famosos pelo Facebook (seus principais desenvolvedores), outros grandes sites utilizam o React para seu frontend, como: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace e Tesla.

Consequentemente, como o React é uma biblioteca na prática (já que ainda carece de recursos notáveis ​​de um framework completo), isso significa que outros 'frameworks' podem ser projetados em cima dele. Resultantly, um deles é Gatsby.js.

Apresentando Gatsby

De acordo com seu site pai, o Gatsby.js é uma estrutura JavaScript gratuita e de código aberto baseada em React que ajuda os desenvolvedores a criar sites e aplicativos rápidos. Em princípio, o Gatsby.js gera páginas HTML estáticas de aplicativos para carregamento inicial e, em seguida, prossegue como um aplicativo React (SPA) de página única.

Atributos do Gatsby.js

Nessas circunstâncias, o Gatsby explora os princípios do Progressive Web App (PWA) para buscar apenas os elementos necessários primeiro e depois carrega o restante do aplicativo em segundo plano. Além disso, para garantir que apenas os dados necessários sejam carregados, o Gatsby aproveita a linguagem de consulta GraphQL (também do Facebook) para carregar os dados da fonte. Ele também mantém uma otimização de imagem excepcional.

Todos esses recursos combinados fornecem aos desenvolvedores as ferramentas necessárias para criar os sites e aplicativos da Web mais rápidos possíveis, pois carrega apenas HTML, CSS, dados e JavaScript críticos. Assim, uma vez que uma página é carregada, o Gatsby pré-busca recursos para páginas vinculadas e, assim, navegar no site parece bastante rápido.

Além disso, como as páginas são geradas na compilação, antes da colocação online, você não precisa mais de servidores PHP poderosos e pode servir arquivos estáticos (HTML, JS e CSS, diretamente do armazenamento do bucket). Além disso, como o Gatsby é desenvolvido pelo React, você poderá estruturar tudo com componentes. Esse aspecto modular permite que os desenvolvedores reutilizem facilmente os componentes.

Outros recursos significativos do Gatsby incluem:

• Gerador de site estático
• Acesso off-line
• Pré-buscando páginas vinculadas
• Cache de página
• Nenhuma busca de código estranho
• Exportar como código
• Conteúdo de recarga quente
• Código de recarga quente
• Componentização
• Ligação de dados unidirecional
• Consultas de dados de API declarativas (GraphQL)
• IU declarativa
• Carregamento progressivo de imagem
• Carregamento de imagem responsivo
• Inlining do CSS crítico
• Auto-hospedagem de fonte
• Sem servidor
• Pipelines de recursos
• Extensões CSS (SaSS)
• Sintaxe JavaScript avançada
• Reagir ecossistema de componentes

Plug-ins Gatsby

Essencialmente, os plugins Gatsby são fundamentalmente pacotes Node.js que usam a API Gatsby. Esses plugins podem adicionar fontes de dados, transformar dados em outros formatos e adicionar serviços de terceiros. Embora o Gatsby.org mantenha uma biblioteca de plugins que inclui muitos plugins já criados pela equipe principal do Gatsby ou por terceiros. Idealmente, para instalar um plugin para um projeto Gatsby, os desenvolvedores empregam o gerenciador de pacotes do nó (NPM) em seu terminal UNIX e executam o comando npm install.

How GraphQL Comes se relaciona com Gatsby.

O GraphQL gira em torno da ideia de que você pode descrever para a API exatamente os dados que deseja e receberá exatamente isso. Como resultado, é mais eficiente que REST. Para isso, Gatsby emprega Webpack e GraphQL. Mais importante, com o GraphQL como linguagem de consulta, tudo é definido do lado do cliente que executa a consulta, com o cliente alheio ao funcionamento do aplicativo.

Essa implementação exclusiva permite que os desenvolvedores conectem qualquer fonte de dados ao Gatsby. Por exemplo, as postagens do blog podem vir de arquivos Markdown, planilhas do Google ou até mesmo de outro site WordPress. Assim, proporcionando maior flexibilidade com a entrega de conteúdo.

Mecanismo Gatsby-WordPress (plugins de origem)

À medida que descompactamos ainda mais esse relacionamento, precisamos entender os plugins de origem. Os plugins de origem são plugins especiais que funcionam no sistema de dados do Gatsby. Como o nome já indica, eles obtêm dados de diferentes locais, locais ou remotos. Consequentemente, os dados são então transformados no que Gatsby chama de nós e campos de nós. Basicamente, os campos de nó representam um único dado dentro de um nó e, em última análise, esses nós podem ser acessados ​​por meio de uma consulta GraphQL.

Na mesma amplitude, por meio de plug-ins de origem, o Gatsby suporta dezenas de opções de CMS headless, aproveitando as equipes de engenharia e conteúdo o conforto e a familiaridade de sua interface de administração preferida com a experiência aprimorada do desenvolvedor e os benefícios de desempenho do uso do Gatsby, GraphQL e React para criar um a parte dianteira.

O plugin 'Gatsby-source-WordPress' é construído e mantido pela equipe principal do Gatsby e extrai dados de sites WordPress auto-hospedados ou WordPress.com. Também envolve autenticação OAuth para a API do Word-Press.com e também permite que os desenvolvedores consultem imagens responsivas.

Essencialmente, este plug-in suporta todas as entidades na API REST do WordPress, como postagens, páginas, tags, categorias, mídia, tipos, usuários, status, taxonomias, metadados do site e tipos de postagens personalizadas. Além disso, as entidades Advanced Custom Fields (ACF) e as informações de idioma Polylang e WPML também são suportadas, além de outras meta de postagem registradas na API REST.

Assim, com este plugin, os desenvolvedores podem escolher quais rotas buscar, embora ele busque todos os endpoints de wpjson por padrão. Assim, os desenvolvedores podem buscar dados do WordPress com GraphQL empregando o mecanismo acima.

Na prática, a ferramenta 'Gatsby-source-WordPress' fornece um slug para todos os posts e outras entidades. E assim, tudo que um engenheiro precisa fazer é criar uma página chamando a função 'createPage'. Isso é executado no arquivo Gatsby-node.js, normalmente executando primeiro a consulta para a fonte de dados e, em seguida, chamando 'createPage' para cada nó encontrado e, em seguida, definindo um arquivo de modelo a ser usado como um componente.

CI/CD e Automação de Liberação de Aplicativos.

Ao implementar um CMS WordPress headless com Gatsby, a forma como a implantação é realizada é altamente crítica. Normalmente, essas execuções exigem que a implantação de um aplicativo seja automatizada utilizando o Application Release Automation (ARA).

Geralmente, ARA envolve funções primárias:

• Implantação de dados, código do aplicativo e artefatos.
• Implantação de configurações específicas para cada ambiente
• Projeto de fluxo de trabalho de processo para automatizar tarefas e etapas de implantação.
• Por fim, os binários de modelagem e/ou provisionamento de ambiente

Como o Gatsby produz sites estáticos, é imperativo configurar um pipeline ARA para que, quando o conteúdo for atualizado no WordPress, ele possa ser atualizado de forma correspondente no site do Gatsby. Normalmente, a implantação contínua é acionada apenas quando o código é alterado, no entanto, para essa instância, é desejável acioná-la quando os dados são alterados. Então, para isso, recomendamos o uso do Netlify pois possui incríveis recursos de implantação contínua embutidos e é fácil de configurar.

Consultando do WordPress usando GraphQL e gatsby-source-WordPress

Como ilustração, gatsby-source-WordPress funciona de forma que primeiro buscará tudo em seu endpoint usando REST. Em seguida, ele gerará uma API GraphQl interna com base nesses dados. Posteriormente, ele passará por suas consultas e reunirá os dados dessa API GraphQL interna. Então, basicamente, sua compilação acaba apenas com os dados que você pediu e nada mais.

Vantagens do desenvolvimento Headless WordPress com Gatsby.js

Já que abordamos o desenvolvimento Headless WordPress com Gatsby, agora podemos detalhar os prós desse tipo de abordagem técnica. Isso deve essencialmente orientar sua decisão sobre adotar ou não Gatsby!

• O primeiro benefício é a capacidade de ter um site estático pré-renderizado. Essa é a maneira mais eficiente de renderizar uma página da Web e, como o Gatsby emprega o GraphQL para executar a quantidade mínima de dados necessária, isso fornece uma eficiência extra para o tempo após o carregamento inicial.
• Melhor visibilidade de SEO: as páginas estáticas são fáceis de ler para os mecanismos de pesquisa, pois tudo é pré-renderizado e indexável. Isso é positivo, em contraste com outros mecanismos headless em que a renderização de páginas com JavaScript é um problema relacionado à otimização de mecanismos de pesquisa (SEO).
• Velocidade de desenvolvimento relativamente rápida: em comparação com outras abordagens headless, o Gatsby tem uma maneira unificada e fácil de entender de buscar dados, independentemente da fonte. Isso torna o desenvolvimento bastante simplificado, pois você pode se concentrar em seu site real e deixar Gatsby fazer a maior parte do trabalho pesado.
• Hospedagem mais barata: você pode hospedar seu aplicativo Gatsby em qualquer lugar, pois ele serve apenas arquivos estáticos, reduzindo assim as despesas de hospedagem. Além disso, como o WordPress é chamado apenas durante o processo de compilação e nunca durante a sessão do usuário, ele também pode ser hospedado em uma solução de hospedagem acessível.
• Segurança Aprimorada: De um modo geral, os geradores de sites estáticos são extremamente seguros, pois não há conexão direta com um banco de dados, dependências, dados do usuário ou outras informações confidenciais.
• Plugin grátis: Do ponto de vista de um não desenvolvedor, o WordPress é bastante fácil de operar por causa dos plugins disponíveis. No entanto, isso restringe a implementação de funcionalidades personalizadas. Infelizmente, muitos plugins também podem tornar um site mais lento, pois ele se torna pesado e mais difícil de renderizar. Uma execução de Gatsby essencialmente contorna todos esses gargalos.

Mais facetas que podem motivá-lo a considerar Gatsby com WordPress:

• Fácil de gerenciar o painel de administração do WordPress.
• Pronto para usar o sistema de login do usuário e autorização.
• Com o editor Gatsby e Gutenberg, você pode criar um construtor de sites Gatsby de arrastar e soltar.

Desvantagens do desenvolvimento Headless WordPress com Gatsby.js

• Limitações de atualização: quando o conteúdo muda do zero, ele define restrições sobre a frequência com que seu site pode ser atualizado. Além disso, pode levar até 10 minutos para executar a compilação do Gatsby se seu site contiver muitos dados, o que pode ser um problema para sites que são atualizados com frequência.
• Atualizações regulares: Além disso, como o Gatsby é um gerador de site estático, ele não pode ser simplesmente “editado”, pois mesmo uma pequena alteração de texto exigirá uma nova implantação. Então, se você tem uma página que requer muitas mudanças de conteúdo dinâmicas diárias, isso pode se tornar demorado e complicado.
• Atrasos: você normalmente precisa esperar vários minutos para ver as alterações em seu conteúdo à medida que elas são publicadas.
• Falta de pré-visualizações: Ao contrário dos aplicativos tradicionais do WordPress, você não tem nenhum tipo de pré-visualização no Gatsby. Infelizmente, esse foi o maior problema que os criadores de conteúdo encontraram com Gatsby. Você precisará compilar tudo, provavelmente com pipelines de CI/CD do Gitlab que compilam o site e colocam tudo online.
• Curva de aprendizado íngreme: Geralmente, se você deseja trabalhar com Gatsby e WordPress ao mesmo tempo, precisa estar relativamente familiarizado com as linguagens PHP e JavaScript. Como o Gatsby mescla o React e o GraphQL, isso pode ser uma curva de aprendizado íngreme para muitos.

Pensamentos finais.

Em conclusão, graças ao seu desempenho e vantagens comerciais, mais empresas estão implementando o Gatsby como parte de sua pilha de tecnologia. Embora seja importante lembrar que ao fundir o Gatsby com o WordPress, o WP se torna apenas backend, o que implica que você perderá algumas de suas funcionalidades e habilidades.

Além disso, os desenvolvedores experientes com o desenvolvimento do WordPress encontrarão o Gatsby como uma ótima ferramenta com seus benefícios modernos de desempenho, escalabilidade, segurança e velocidade de desenvolvimento. Tudo isso, permitindo que eles mantenham a interface de usuário familiar de criação de conteúdo oferecida pelo WordPress.

No entanto, antes de iniciar esta tecnologia, deve-se sempre considerar suas especificações e objetivos de projeto. Por exemplo, se a ênfase estiver em escalabilidade, desempenho, velocidade de desenvolvimento, ciclo de vida longo, Gatsby servirá. No entanto, se a ênfase é ter flexibilidade e ferramentas aprimoradas para criadores de conteúdo não programadores com conteúdo atualizado em um segundo ou minuto, você pode considerar uma abordagem alternativa.