Migração do WordPress para o Jamstack

A Grande Migração: Migrando do WordPress para o Jamstack

Se você trabalha com desenvolvimento, edição ou redação na internet, provavelmente já ouviu falar do WordPress. Dizer que ele é prolífico é um eufemismo.

Sempre que falamos sobre a participação de mercado de diferentes frameworks, alguém inventa um novo número do nada para o WordPress — uma excelente observação feita por Sarah Drasner ao escrever sobre quando a a Smashing Magazine mudou do WordPress para o Preact/Hugo no início deste ano.

Tenho sido bastante franco sobre minhas críticas ao WordPress – segurança, velocidade, excesso de recursos e experiência do usuário. Sem querer desmerecer os desenvolvedores do WordPress, nem as pessoas que cuidam da manutenção dele, mas para uma organização como a nossa — com engenheiros, redatores e profissionais de experiência do usuário disponíveis para contribuir —, conviver com uma plataforma amplamente considerada desajeitada e pesada apenas em prol de um bom backend sempre me pareceu um pouco contraintuitivo.

Então, assim como no post da Sarah, vou explorar os “o quê”, “por quê” e “onde” dessa jornada, desde aquele encontro que tivemos em Miami, no início de 2020, antes que o mundo parecesse entrar na, bem, era da COVID.

Por quê?

Estávamos passando por uma reformulação da marca, e o momento não poderia ter sido melhor para nós. Por que investir em uma agência para reformular nosso site do WordPress se podíamos criar um novo site baseado na nossa marca, do zero?

Além disso, nosso processo de criação de conteúdo estava dividido entre três plataformas. Nosso conteúdo era editado e revisado no formato Markdown, transferido para o WordPress e acompanhado no JIRA.

Como mencionei acima, estávamos bem cientes das preocupações gerais em relação à velocidade e à segurança do WordPress.

Além disso, esse site do WordPress representava uma parte da nossa infraestrutura desconhecida por quase toda a nossa equipe de operações. A Vonage continua trabalhando na consolidação da infraestrutura das empresas de API que adquiriu nos últimos anos, e nossa plataforma do WordPress era um resquício desnecessário desse legado.

Confiabilidade

Nossa equipe de Educação para Desenvolvedores faz parte do departamento de Relações com Desenvolvedores, que, por sua vez, está inserido na organização de Produtos. Portanto, não somos engenheiros em tempo integral e não administramos grandes quantidades de infraestrutura.

O Netlify nos permite publicar nosso conteúdo sem precisar nos preocupar com nada depois. Podemos superar as preocupações com complexidade, manutenção, segurança e confiabilidade que o WordPress traz consigo. Com o Netlify, desde que nosso site possa ser compilado, ele pode ser implantado.

Fluxo de trabalho

Como já mencionei, tínhamos um fluxo de trabalho dividido entre três plataformas. Isso podia ser frustrante e dificultar o acesso, especialmente para redatores externos que não tinham acesso ao nosso repositório de conteúdo, como os participantes do nosso programa Spotlight.

Um dos objetivos deste projeto era encontrar uma maneira de simplificar nosso fluxo de trabalho, de forma que isso tivesse o menor impacto possível sobre nós. O Netlify CMS nos permitiu fazer isso.

O fluxo de trabalho editorial oferecido pelo Netlify CMS refletia bastante o nosso fluxo de trabalho existente no JIRA, o que me deu esperanças de automação (ou, ainda, mais uma oportunidade de acessar o JIRA com menos frequência). Ao mesmo tempo, o armazenamento baseado em Git do Netlify CMS também refletia nosso processo de revisão existente.

O uso do Netlify CMS permitiu a consolidação de uma parte significativa do processo.

A migração do conteúdo do WordPress acabou sendo o maior obstáculo que enfrentamos. Tínhamos a API REST do WP disponível, então comecei a fazer uma chamada de API atrás da outra para tentar identificar a melhor maneira de extrair nosso conteúdo do WordPress. Editávamos o conteúdo no WordPress em Markdown, então ele deveria armazená-lo dessa forma, certo? Fiquei animado ao pensar que poderia fazer algumas chamadas de API para recuperar nosso Markdown e salvá-lo como arquivos Markdown.

Mas será que estava armazenado como Markdown? Devido à natureza dos plug-ins desenvolvidos pela comunidade e sem manutenção, nada acabou sendo tão simples assim.

Nossas postagens armazenadas no WordPress eram renderizadas como HTML. O Crayon, o antigo e abandonado plugin de realce de sintaxe, parecia manter o código em tabelas, com colunas para números de linha e linhas para cada linha de código. A última versão do Crayon antes de ser descontinuado mencionava a mudança para armazenar o código em <pre><code> , assim como outros realçadores de sintaxe. O objetivo da última atualização era tornar a migração mais viável, já que seria compatível com conversores ou até mesmo com outros realçadores. Mas, infelizmente, o plugin era tão antigo e o site estava tão negligenciado que enfrentávamos um obstáculo irrealista para atualizar tudo e publicar o conteúdo.

A incrível ironia do Crayon é que o mantenedor também já estava cansado do WordPress e decidiu migrar seu site e passar a se dedicar ao Jekyll, uma plataforma Jamstack.

Decidimos revisar todo o nosso conteúdo manualmente. Não temos os milhares de artigos da Smashing Magazine, mas temos mais de 500 conteúdos. Mencionei a reformulação da marca anteriormente. Essa decisão nos permitiu revisar cada conteúdo para atualizar a identidade visual, atualizar as versões do SDK, solicitar novas ilustrações e trazê-los para 2020 (coitadinhos).

Mas, como você pretende produzir novos conteúdos E revisar todos os conteúdos em questão de semanas? Bem, você não vai fazer isso. O plano seria realizar a revisão dos conteúdos ao longo de alguns meses.

O Plano

Usando regras de reescrita, impediríamos que as pessoas acessassem o site antigo. Elas seriam redirecionadas para a mesma postagem no novo domínio, onde os metadados seriam importados como arquivos Markdown.

O site antigo seria transferido para um novo domínio “legado”, com um link para ele em cada postagem que importarmos.

O novo site exibiria então uma mensagem do tipo “Ainda estamos migrando este conteúdo”, com uma contagem regressiva para redirecionar os usuários ao link antigo.

À medida que migramos o conteúdo, editamos o arquivo Markdown que já importamos, removendo o link antigo e adicionando o conteúdo migrado, inserindo-o no meio da experiência do usuário. O objetivo é limitar o impacto sobre o usuário e reduzir a carga de trabalho da equipe para que possamos migrar todo o nosso conteúdo rapidamente.

Para limitar ainda mais o impacto, priorizamos a migração dos nossos conteúdos mais lidos e mais recentes, migrando a maioria deles antes de entrarmos no ar.

Opções de estrutura

Eu já tinha alguma experiência trabalhando com o Jekyll e um fluxo de trabalho semelhante no passado. O Jekyll, quando configurado corretamente, é extremamente rápido na renderização. Eu diria que ele ainda está entre os melhores em termos de velocidade de compilação quando comparado a outras plataformas Jamstack. Pareceu-me certo começar por aí, com algo que eu sabia que funcionava.

Eu também vinha experimentando o Nuxt.js, porque o Vue.js é incrível e sou um grande fã do Jamstack em geral. Combinando minhas duas coisas favoritas (Vumstack? Jamue?), descobri o Nuxt.js! A Vonage também tinha um sistema de design chamado Volta, baseado no Bootstrap, que aplicava todas as nossas diretrizes de identidade visual e estava disponível como uma biblioteca do Vue.js.

Então, criei duas provas de conceito: uma no Jekyll e outra no Nuxt.js. Apesar de os modelos Liquid serem, em geral, muito mais fáceis de trabalhar, percebi que conseguia criar protótipos no Nuxt.js com muito mais rapidez graças ao Volta. Com um front-end que já ficava ótimo com nossa identidade visual e renderização do lado do servidor para tornar o site extremamente rápido, ficamos muito empolgados com esse protótipo em Nuxt.js. Após algumas semanas de ajustes e incorporação de sugestões, chegamos a algo próximo do que temos hoje.

O Nuxt.js foi a escolha certa!

Duas semanas após a conclusão da nossa prova de conceito, o Volta foi descontinuado pela equipe de design! Nós o substituímos pelo TailwindCSS, o que nos permitiu alcançar a paridade de design com o Volta, mas com pontos de quebra mais previsíveis e um número maior de utilitários para sites responsivos.

Conclusão

O resultado para nós foi transformador. Vamos poder oferecer mais tipos de conteúdo, com mais rapidez e confiabilidade. Agora temos uma plataforma que dá suporte a todas as nossas metas imediatas para 2021 e para o futuro. Além disso, ela está INCRÍVEL, modéstia à parte.

A migração continua, mas o dia da entrada em operação transcorreu sem contratempos. Fizemos a transição das pessoas para a nova plataforma sem problemas, com redirecionamentos para o sistema antigo, caso fosse necessário.

Graças às análises do lado do servidor, estamos obtendo um acompanhamento mais preciso do que antes e temos acesso a dados muito mais detalhados para orientar nossas metas de redação no futuro.