No passado, o Psono.com era alimentado pelo Odoo v11. O Odoo é um ótimo CMS, mas como tivemos que aprender, as atualizações são difíceis. Especialmente o módulo de site deles produziu muitos problemas durante nossos testes. O Odoo v11 chegará ao fim de sua vida útil no final de 2020, então fomos forçados a encontrar uma solução.
Pensamos sobre diferentes opções: atualizar para o Odoo v13 e migrar manualmente todo o conteúdo e personalizações, contratar alguém para fazer a migração por nós ou migrar completamente para um novo CMS. Decidimos migrar completamente o Psono.com e continuar a usar o v11 atrás de um firewall e migrar posteriormente (ainda não decidimos).
As razões por trás dessa decisão foram:
- Temos apenas uma pequena quantidade de conteúdo que precisaríamos migrar para o Psono.com. Principalmente alguns posts no blog.
- Uma migração para o Odoo v13 reproduziria o mesmo problema em dois anos, quando v13 atingir o seu EOL, potencialmente com muito mais dados para migrar.
- Não estávamos muito felizes com as capacidades de personalização dos sites do Odoo v11. Tudo é extremamente complexo com seus templates sendo armazenados no banco de dados.
- Os custos. Contratar alguém para fazer a migração nos custaria pelo menos 5000 USD, possivelmente mais.
- A comunidade do Odoo era muito ativa, mas com o desenvolvimento nos últimos anos de mudanças de licença e a migração de funcionalidade e plugins para soluções pagas e colocando tudo atrás de um paywall, a comunidade está morta.
- Psono.com é principalmente um site estático com conteúdo estático. Se precisássemos de conteúdo dinâmico, poderíamos puxá-lo com APIs.
A jornada
Depois de tomar a decisão de migrar, tivemos que decidir qual framework usar. Existem frameworks clássicos, como por exemplo, Hugo, que usamos, mas sua funcionalidade é limitada. Enquanto procurávamos alternativas, encontramos algumas soluções no mundo Node / React.
Queria escrever aqui "soluções excelentes", mas não acho que nada no estado atual quebrado do desenvolvimento de frontend mereça esse título. Quebrado você pergunta? Lembre-se dos tempos em que os desenvolvedores podiam criar um site com um index.html e uma tag script para carregar o jquery e começavam a desenvolver sites? Agora você precisa de npm ou yarn, precisa entender package.json, scripts webpack, frameworks modernos como angular ou react, que trazem seu próprio cliente com eles. JSX ou typescript. Recursos como recarregamento a quente não funcionam de forma confiável (arquivo não monitorado, algumas modificações precisam de um reinício completo, ou o recarregamento a quente é acionado muito cedo, então você tem que atualizar manualmente de qualquer forma), então você acaba matando os servidores de desenvolvimento e esperando minutos para que voltem (pelo menos em projetos maiores). (Eu sinto falta de apertar F5 e tudo estava lá sem problemas!). Sem mencionar um novo framework ou ferramenta pelo menos a cada seis meses, onde as ferramentas antigas são abandonadas diariamente. Eu poderia facilmente preencher páginas reclamando sobre o estado atual do desenvolvimento de frontend. De qualquer forma, voltando ao tópico real.
Na ausência de alternativas sensatas, as melhores opções (no momento em que escrevo isto) seriam next.js e gatsby. Pelo menos é assim que alguns artigos os promovem. Ambos são igualmente populares se você comparar estrelas ou commits do Github. A única diferença que pudemos notar durante uma avaliação inicial é a exigência de um componente de servidor para next.js, enquanto gatsby cria sites estáticos (Por favor, não me mate agora se houver uma opção para rodar next.js sem um servidor ativo :D).
Então, brincamos um pouco com o Gatsby e parecia bom. Como próximo passo, começamos a procurar um tema. O Gatsby é uma utilidade "nova", então todos os temas que pudemos encontrar ainda estavam em um estado muito básico. Trinta minutos e trinta dólares depois, tínhamos um tema visualmente atraente que cobria pelo menos alguns dos componentes necessários e começamos a modificá-lo.
Como opção de hospedagem, hoje em dia, você pode escolher entre vários provedores, nomeadamente Firebase, netlify, Cloudflare, Vercel, simples armazenamento em nuvem GCP ou AWS Cloudfront, próprios servidores, containers Docker rodando no Kubernetes (eu tinha que mencionar isso!), ... (Lembre-se dos velhos tempos em que você apenas alugava um espaço na web por 5 dólares por mês com PHP e um banco de dados MySQL :D ... mas isso é para outro artigo...)
Depois de compará-los, ler algumas avaliações e verificar possíveis combinações (como Cloudflare na frente do Firebase), inicialmente tentamos o Cloudflare. Como grandes fãs do serviço deles, foi uma escolha natural, mas infelizmente a utilidade wrangler deles teve problemas. Primeiro, estava sempre gerando um erro e depois não conseguíamos autenticar... Os erros iniciais desapareceram no dia seguinte (talvez um novo bash tenha resolvido), mas o problema de autenticação persistiu. Acho que devo ter cometido algum erro e desisti depois de algumas horas lendo a documentação e tentando diferentes soluções.
O Netlify era outro candidato, mas você tem que conectá-lo a um provedor git e deixá-los compilar (queríamos usar o GitLab CI) ou fazer o upload manualmente do output da compilação. Talvez eles tenham uma opção em algum lugar para fazer upload do output da compilação através de uma API, mas eu não consegui encontrar uma. Uma alternativa seria um repositório onde realmente empurramos o output da compilação, mas isso parecia desnecessariamente complexo... Outro problema para mim é o modelo de preços deles. Eles cobram por membro (!!!) uma quantia bastante substancial. Tenha em mente que isso é para um site estático. Declarações como "4x largura de banda" trazem más lembranças de tempos de "hospedagem web de uso justo", onde as pessoas chutavam você se você usasse demais...
Como quarto serviço, tentamos o Firebase (que como benefício é gratuito para nossa largura de banda e solicitações alvo) e tudo funcionou imediatamente. Suas capacidades de redirecionamento são um pouco limitadas, então mapear URLs antigas para mais bonitas se tornou um pouco tedioso, mas algumas regras de redirecionamento depois, tudo estava funcionando. Seus preços parecem razoáveis e você é cobrado pelos recursos do servidor. Deve-se ficar longe de todos os serviços extras para evitar dependência do fornecedor, mas precisávamos apenas de hospedagem.
Também verificamos brevemente o Vercel, mas a exigência de fazer login com uma conta do Github e depois uma permissão com "Agir em meu nome" me afastou antes mesmo de me inscrever.
O blog foi o mais difícil de migrar. Acabamos copiando todo o conteúdo manualmente. Isso não é algo que você deve fazer com um blog maior, mas nosso blog tinha apenas quinze posts. O Gatsby suporta vários mecanismos, mas queríamos algo simples que alguém sem conhecimento técnico pudesse criar novos posts no blog. Decidimos usar markdown e, como tal, tivemos que aprender a instruir o Gatsby a ler páginas em markdown. O mecanismo real nos levou cerca de meio dia com todo o manuseio de imagens. Um tema de post de blog agradável e imagens, outro meio dia.
Depois de migrar todo o conteúdo e modificar ainda mais o tema, automatizamos nosso deployment com Gitlab CI, então um simples push acionava nosso pipeline de construção e implantava tudo no Firebase.
Por que Gitlab e não Github? O Github tem a liderança por razões históricas. Atualmente, eles têm pelo menos 80% de todos os desenvolvedores e projetos. O Gitlab, por outro lado, entrega recursos. É por isso que no passado decidimos usar o Gitlab, pois não houve desenvolvimento real de funcionalidades no Github por anos. Isso mudou drasticamente desde que a Microsoft comprou o Github e o Github Actions é um marco, mas o Github ainda tem um longo caminho a percorrer se quiser competir com o Gitlab. Então, para nós, que hospedamos todos os nossos projetos no Gitlab, foi uma escolha natural usá-lo para este projeto também.
A conclusão
E é aí que estamos agora:
- Gatsby como CMS
- Tema comercial
- Blog alimentado por Markdown
- Gitlab CI para deploys automatizados
- Firebase Hosting
Ficamos bastante felizes com esse resultado e o novo site está muito melhor!
