Como a Smashing Magazine gerencia o conteúdo: migração do WordPress para o JAMstack

Este artigo foi gentilmente apoiado por nossos queridos amigos da Netlify, uma plataforma tudo-em-um para automatizar projetos modernos da web. Obrigado!

Toda vez que os desenvolvedores falam sobre o WordPress, sua porcentagem de participação de mercado muda. “ 20% de todos os sites estão no WordPress! ” “ 40% de todos os sites estão no WordPress! ” Qualquer que seja a porcentagem, a mensagem é a mesma: em termos de adoção, o WordPress é MASSIVO.

Então, por que, com esse tipo de adoção, um site que usa o WordPress consideraria migrar para o JAMstack? Nesta série de artigos de duas partes, abordaremos como é uma migração real do WordPress, usando um estudo de caso do próprio site que você está lendo agora.

Falaremos sobre os ganhos e perdas, as coisas que gostaríamos de saber antes e o que nos surpreendeu. E, em seguida, seguiremos com uma demonstração técnica de um caminho de migração possível - não completamente fora do WordPress - mas como você pode servir o WordPress desacoplado para que você possa ter o melhor dos dois mundos: uma implementação JAMstack do WordPress que oferece tudo o poder de seu painel e funcionalidade, com melhor desempenho e segurança.

Vamos cavar!

Por quê?

Em 2015, o cofundador da Netlify, Mathias Biilmann, e o fundador da Smashing, Vitaly Friedman, conversaram. À medida que a arquitetura JAMstack começou a circular, o Smashing ficou mais interessado na ideia da pilha. Vitaly e Markus (ex-diretor administrativo da Smashing) perguntaram a Matt o que aconteceria se a Smashing migrasse de seu site WordPress/LAMPstack tradicional para uma arquitetura JAMstack.

Como um experimento, Matt raspou todo o HTML do Smashing e o hospedou no Netlify, entregando o conteúdo estaticamente de um CDN. Os resultados foram convincentes - a versão estática é mais de seis vezes mais rápida, em média!

Esse tipo de arquitetura funciona tão bem em parte porque as páginas não estão sendo compiladas sob demanda conforme você as visita. Como você está servindo conteúdo pré-criado diretamente de uma rede de distribuição de conteúdo , o site já está “lá” e pronto para o usuário.

Como você está servindo via CDN, você também pode distribuir o conteúdo em todo o mundo — mais perto de visitantes em potencial. Não há um ponto central de origem, o que é vital no caso de qualquer publicação online que queira ser rápida para todos os seus leitores.

Então o palco estava montado. A Smashing Magazine migrou para o JAMstack — para a Netlify como plataforma em particular. Em seus 10 anos de operação, o Smashing cresceu de uma pequena publicação online para um enorme blog WordPress, vendendo coisas como livros, ingressos para conferências e workshops.

Havia algumas peças deste site:

• blog WordPress
• quadro de empregos Rails
• Loja da Shopify
• Outro CMS para o site da conferência

Quando a Netlify começou a migração, o site estava sofrendo alguns problemas de desempenho, sobrecarregados por 20 mil comentários e milhares de artigos. A Smashing também estava interessada na autenticação como parte de um novo plano de assinatura, bem como em um redesenho para uma aparência mais moderna.

Confiabilidade

Smashing regularmente alcança o que outras plataformas sonham: artigos compartilhados amplamente por uma enorme comunidade. No entanto, quando um ponto de inflexão de tráfego era alcançado para uma postagem, o Smashing regularmente tinha problemas com interrupções. Para mitigar isso, o uso pesado de plugins do WordPress foi introduzido em sua pilha, mas eles ainda lutavam para manter boas métricas de tempo de atividade.

A mudança para o Netlify permitiu que a equipe do Smashing evitasse erros de conexão com o banco de dados e não se preocupasse com o tempo de inatividade , mesmo quando um artigo visse uma grande quantidade de tráfego. Por quê? Porque ao servir sem um servidor, o conteúdo pré-construído não precisa ser gerado e servido — ele já existe, pronto para ser visualizado. Nada está sendo solicitado no local, exceto a página inteira e estática.

Servir via CDN também permitiu que o Smashing dormisse um pouco mais fácil em termos de segurança. wp-login.php tem sido uma fonte de falhas de segurança e vetores de ataque. O conteúdo pré-construído não pode ser acessado da mesma maneira e as falhas de segurança não são tão onipresentes.

Invalidação de cache

Smashing passou por todos os plugins de cache do WordPress, com resultados variados e muitos problemas. Vitaly Friedman de Smashing menciona,

“Os principais problemas que tivemos foram relacionados a 'Erro ao estabelecer conexão com o banco de dados' que continuávamos tendo a cada duas semanas, e literalmente tentamos todos os plugins de cache do WordPress disponíveis. O desempenho foi muito bom (no geral), mas estávamos procurando melhorá-lo ainda mais. Além disso, queríamos lançar o Membership e conectar todas as diferentes ofertas – conferências, vagas de emprego, artigos, livros, eBooks – com uma única plataforma, e foi notavelmente difícil de alcançar com o WordPress em jogo.”

A mudança para o Netlify permitiu que a equipe do Smashing visse a invalidação instantânea do cache, além de servir conteúdo em cache e de alto desempenho, sem sobrecarga extra.

Quando você implanta um site, os arquivos HTML são hospedados na CDN da Netlify. Ele é otimizado para uma alta taxa de acertos de cache e tempo rápido para o primeiro byte, sendo capaz de invalidar instantaneamente todos os arquivos HTML que foram alterados. O Netlify também imprime todos os links para ativos como arquivos CSS, imagens, fontes ou arquivos JS e serve o Smashing com cabeçalhos de cache que os armazenam em cache para sempre. A impressão digital garante que eles sejam exclusivos e que, se você atualizar uma nova versão, a versão mais recente será veiculada.

Fluxo de trabalho

Observando a configuração existente, um grande motivo para a migração foi simplesmente unificar as propriedades existentes. Ter que mudar o contexto entre todas essas diferentes pilhas e configurações de tecnologia se tornou um problema de manutenção difícil que encarregou os engenheiros.

Quando anteriormente sua infraestrutura era dividida entre tantos sistemas diferentes, esse processo de migração também unificou tudo , mantendo o site principal, o site de conferências, as assinaturas e a seção de e-commerce trabalhando juntos em vez de mantidos separadamente com pilhas diferentes. Isso ajudou a manter os custos de desenvolvimento baixos e a experiência do desenvolvedor trabalhando em todas as propriedades de forma consistente.

A peça de migração do WordPress provou ser a maior e mais delicada. A Netlify tentou exportar os dados do exportador WP, apenas para descobrir que o conteúdo tinha embeds que precisavam ser preservados ou, às vezes, alterados por plugins. Para manter a paridade com o que estava no site, uma série de scrapers foi escrita, dividida por artigos, ativos, comentários e página inicial.

Uma vez que foi escrito e transformado, foi carregado em um novo repositório no GitHub, e o Netlify CMS foi usado em seu lugar. O que torna o Netlify CMS único é que ele é leve e integra editores de conteúdo em um fluxo de trabalho Git - o que significa que ele literalmente puxará e servirá arquivos markdown de um repositório git em vez de um banco de dados. Além disso, o Netlify CMS é independente de plataforma e funciona com (quase) todos os geradores de sites estáticos e sites armazenados no GitHub.

Naquela época, Sara Soueidan trabalhava para a Smashing como desenvolvedora freelancer de front-end em seu redesenho. Ela criou uma biblioteca de componentes para construir a arquitetura front-end e observou como era muito mais simples trabalhar com ela porque estava trabalhando diretamente no git, mesmo quando trabalhava com o CMS.

“Tudo o que eu enviei para o repositório está sendo aplicado diretamente à biblioteca de padrões, o que significa que você não precisa manter dois conjuntos diferentes de componentes... esse tipo de continuidade foi ótimo! Tudo o que tenho a fazer é escrever HTML, CSS e JavaScript e enviar para o repositório e tudo funciona como mágica. O fluxo de trabalho foi fantástico.”

Dito tudo isso, o Netlify CMS às vezes pode ser muito leve para um caso de uso de alto tráfego e escala. Smashing regularmente tem autores convidados e uma equipe editorial completa. Alguns dos recursos avançados que o WordPress oferece são realmente úteis para esses tipos de ambientes altamente colaborativos.

É por isso que no tutorial a seguir, vamos orientá-lo através de um modelo headless , onde você ainda pode colher os benefícios do painel do WordPress para criadores de conteúdo, mas use o WordPress via API e faça com que o desenvolvimento dependa de um fluxo de trabalho centrado no git tão fácil para os desenvolvedores manterem também. Fique ligado!

Opções de estrutura

No protótipo inicial que Matt Biilmann criou, ele escreveu tudo em Preact mínimo, emparelhado com Hugo, pois ele era muito focado em performance. Ele apenas usou adereços e manteve tudo muito leve. Quando ele passou o projeto para ser mantido pelo desenvolvedor do Smashing, Ilya Pukhalski, ele descobriu que Preact estava faltando alguns recursos que estavam faltando para explorar o ecossistema do React. Eventualmente, os benefícios do Redux e de outras bibliotecas superaram o custo.

Refletindo agora, Matt diz que teria usado o Vue, que não tinha muita participação de mercado na época (juro que não o instiguei a dizer isso). Fiz a pergunta óbvia: por que não Svelte? Como as pessoas preocupadas com o desempenho tendem a buscar essa biblioteca. Ele mencionou que o Svelte ainda não tem o ecossistema que o Vue tem.

Quando Matt reflete sobre se ele ainda usaria ou não Hugo, ele diz que ama Hugo, mas o que ele achou difícil para este projeto em particular foi que ele não tinha um sistema de plugins suficiente - criando banners e coisas de que a natureza não era programável o suficiente com Hugo e ele precisava injetar scripts para realizá-lo. Esses scripts tendiam a desacelerar o processo de compilação. Dito isso, ainda usamos Hugo para nosso próprio site em netlify.com e adoramos - essa ressalva é extremamente específica para as necessidades do site do Smashing em particular.

Se ele pudesse fazer isso de novo, ele poderia escolher o Eleventy, que possui recursos ricos em termos de criação de plugins e outros scripts extensíveis. Ou, se ele estivesse usando o Vue, o Nuxt teria oferecido a ele alguns bons recursos de plug-in, permitindo ser uma boa escolha para esse framework, oferecendo renderização do lado do servidor, roteamento e geração estática.

Construindo grandes sites

Houve um problema que surgiu trabalhando com um site tão grande quanto o Smashing e talvez você já possa descobrir o que é, acabamos de tocar nele. É verdade que com qualquer site grande de páginas pré-construídas veiculadas em uma CDN, o desempenho ainda é ótimo porque não estamos construindo nada dinamicamente para os usuários.

Mas esse benefício só pode acontecer se o site for pré-construído e esse processo pode ser demorado. Embora os sites mais tradicionais criem as páginas quando você as solicitar, estamos literalmente criando cada página com antecedência, caso o usuário precise. Isso torna o desempenho super rápido! Mas esse tempo agora é transferido para o tempo de desenvolvimento e publicação – criar cada página pode levar tempo.

Isso não é tanto um problema com sites menores, mas na escala da Smashing Magazine, precisamos pensar um pouco mais sobre esse tempo, especialmente para que as pessoas possam manter a produtividade alta enquanto criam conteúdo ativamente diariamente.

O que a Netlify fez foi criar uma grande pasta /production-articles que carregava a maior parte dos muitos milhares de artigos que eles já hospedavam. Em seguida, criou um diretório de trabalho separado chamado content/articles onde os artigos que estavam sendo criados e editados ativamente poderiam ser colocados.

Esse processo de construção significava que todos os que estavam trabalhando no site estavam trabalhando com um lote menor de artigos para desenvolvimento local, sem o impedimento de esperar por toda a construção. Esse processo foi gerenciado por uma tarefa de gulp para preparar os artigos de produção e liberou Hugo para lidar apenas com o que estava sendo trabalhado ativamente.

Um dos contras dessa abordagem é que ela ainda exige que toda a compilação seja executada, tornando o processo lento. Em uma publicação menor, isso provavelmente importaria menos, mas na escala do Smashing, isso desacelera o processo de publicação.

APIs de código aberto

No início, mencionamos que, entre outras coisas, a Smashing estava interessada em migrar sua solução de comércio eletrônico existente, lidar com comentários fora do WordPress e adicionar funcionalidades para autenticação. Todas essas funcionalidades foram criadas com soluções de código aberto que a Netlify mantém, dividindo-as em APIs sem estado:

• GoTell
  Uma API e ferramenta de construção para lidar com grandes quantidades de comentários.
• GoCommerce
  Uma pequena API baseada em Go para sites de comércio eletrônico que lida com pedidos e pagamentos.
• GoTrue
  Uma pequena API de código aberto escrita em Golang que pode atuar como um serviço de API independente para lidar com o registro e autenticação de usuários para projetos. Ele é baseado em OAuth2 e JWT e lidará com a inscrição do usuário, autenticação e dados personalizados do usuário.

Cada uma dessas peças exigiu migração e fatores únicos próprios e, embora estejam fora do escopo deste artigo, todas elas são abordadas em um livro gratuito que Matt co-escreveu chamado “ Modern Web Development on the JAMstack ”. Também faremos alguns mergulhos profundos como este - com exemplos úteis - em pesquisa e autenticação, em postagens subsequentes.

Conclusão

A migração correu bem. Esmagadoramente? Er... correu bem. Smashing não foi penalizado por seu próprio sucesso - quando um artigo popular aparecia, eles podiam servir o conteúdo de forma consistente, não mais carregando grandes cargas. Junto com isso, a mudança para uma infraestrutura JAMstack trouxe melhor desempenho e segurança.

Markus Seyfferth, ex-CEO da Smashing Magazine, observou:

“O tempo para o primeiro carregamento é muito mais rápido do que antes… antes tínhamos que esperar o arquivo HTML ser servido por 800ms e agora são 80ms .”

Esse processo foi bem-sucedido e, como qualquer grande projeto de engenharia, as lições foram aprendidas ao longo do caminho. Neste próximo artigo desta série, veremos um tutorial e uma demonstração do que recomendamos com base no que aprendemos. Se você deseja modernizar seu desenvolvimento WordPress e colher os benefícios de desempenho e segurança do JAMstack, continue lendo!