Coisas que Aprendi com um Projeto Supostamente Simples

Fala galera! Há pouco postei um texto no meu Medium e, como sempre gosto de fazer, estou replicando na íntegra aqui também. Acho que essas discussões são bacanas e espero estar ajudando de alguma forma a comunidade TabNews dessa forma. Como sempre, segue o link para quem quiser ver o artigo na forma original, com imagens: https://igorstefano.medium.com/coisas-que-aprendi-com-um-projeto-supostamente-simples-8461bdd763cc

Opa!

A quem estiver lendo este blog, pode ou não saber que recentemente publiquei um projeto pessoal chamado Qual É o Próximo Feriado, com a simples e direta intenção de responder essa pergunta de um jeito engraçadinho (detalhes técnicos no repositório ou no Pitch)

É um site extremamente simples, de uma página só e pouquíssimas interações, pesadamente influenciado pelo Should I Deploy Today e Devo Deployar. Seria de se pensar que alguém com alguma experiência em desenvolvimento como eu não teria o menor problema em criar algo do tipo. Esse pensamento está parcialmente correto, o desenvolvimento da primeira versão do site (que ainda teve diversas iterações antes da forma atual) deve ter levado algumas horas no máximo.

Todavia, como todo projeto é uma oportunidade de aprendizados - e porque nesse projeto específico, os meus esforços foram para além do escopo do desenvolvimento - gostaria de falar sobre algumas coisas que aprendi desenvolvendo um projeto que alguns considerariam trivial.

Certificados SSL são complicados

Como falei em outras oportunidades, esse projeto está sendo hospedado no Magalu Cloud, em um servidor rodando a partir de uma VM lá. Admito que não tenho tanta experiência com esse tipo de coisa, e tive bastante ajuda para fazer essa configuração inicial do meu amigo André Balieiro alguns meses atrás.

Acontece que ao realizar essa configuração, colocamos uma automação para que o certificado SSL do domínio fosse atualizado de maneira automática e recorrente. Qual não foi minha surpresa ao subir o site e descobrir que ele havia realmente expirado?
Fiquei um ou dois dias tentando resolver a automação, mas no final das contas só atualizei o certificado manualmente. Certificados SSL são coisa séria, os navegadores não recomendam entrar em sites que não estejam em dia com ele, então para lançar o que fiz, era mais importante estar funcionando. Com certeza mais pra frente quero garantir que essa automação funcione para evitar a fadiga.

Importância da diferença entre vh e dvh

Essa foi provavelmente a minha lição favorita deste projeto, uma vez que é um problema de Front-end que eu mesmo nunca tinha notado. Se você olhar o design do site, perceberá que no fundo da página existe um footer, com o link para o repositório do GitHub.

Este footer está aí desde as versões iniciais do site. Todavia, ele ficava escondido abaixo de um scroll, apenas na versão para celulares. Na versão do computador e até mesmo a prévia gerada no Dev Tools isso não ocorria. Por quê?

Eu havia usado, no container maior, o valor de 100vh como altura. Em tese, isso está certo, eu gostaria de ocupar todo o espaço disponível da tela. Por que isso gerava um scroll no mobile então? O problema é que a medida de viewport height nos dispositivos móveis leva em conta inclusive o espaço que é ocupado pela UI do dispositivo e do navegador. Isso significa que 100vh é um valor ligeiramente maior do que o espaço ocupado na tela. Como resolver isso sem quebrar a experiência do desktop, que funcionava perfeitamente?

Essa dor era tão comum que foram criadas medidas nos padrões da web para resolver exatamente esse caso de uso: lvh, svh e dvh. Sem querer entrar em muitos detalhes, substituir a instrução de 100vh para 100dvh bastou para garantir uma experiência consistente em todos os tamanhos de tela.

Às vezes, menos é mais

Como este é um site que diz qual é o próximo feriado, faz sentido que responder essa pergunta seja uma preocupação crucial para construí-lo. A verdade é que é mais complicado do que parece responder essa pergunta, pois feriados nacionais nem sempre são no mesmo dia do ano (por exemplo, o Carnaval ou a Sexta-feira Santa).

O jeito mais correto de resolver isso poderia ser usar a Brasil API, que nos traz corretamente quais serão os feriados nos próximos 12 meses. Ainda assim, ao lidar com uma API externa, deve-se ter diversas considerações; validação das informações, plano B em caso de indisponibilidade ou falha... Então decidi simplesmente pedir a uma LLM gerar um JSON da maneira como eu gostaria de receber os dados, com os feriados até dezembro de 2025. Outra ausência conspícua a quem vê o código é a de testes automatizados.

Essas escolhas acima trazem malefícios claros. Um código sem testes é um código mais difícil de se estender. Um JSON que se expira em 2025 praticamente decreta a data de validade do site como um todo. Mas ao mesmo tempo, elas me permitiram me mover com agilidade no que mais importava: usando meu tempo escasso, criar a primeira versão e mostrar ao mundo para que eu mesmo saiba se daqui a um ano fará sentido manter esse site em pé.

Tomar essas decisões de maneira consciente não é fácil para alguém que, como eu, se importa com a qualidade de código, todavia fico feliz que tomei, pois olhando agora acredito que foi o único conjunto de decisões que permitiriam que o site fosse lançado.

Workflows no GitHub Actions

Eu nunca havia criado uma pipeline de CI do zero antes. Nesse projeto, mesmo após a publicação inicial, diversos ajustes ainda foram necessários, então foi basicamente inegociável implementar. Como decidi hospedar meu repositório no GitHub, decidi usar o GitHub Actions para fazer isso.
Com a ajuda do ChatGPT e bastante paciência (foram mais de 20 jobs fracassados antes de dar certo), criei uma pipeline bem rudimentar para atualizar o código da VM sempre que atualizasse a branch main. Apesar da minha dificuldade, esse passo é um começo simples, porém crucial para viabilizar as atualizações de código após publicar em ambiente de produção.

Conclusão

Como tenho pouca expertise nesse mundo de DevOps, foi de se abrir os olhos realmente colocar a mão na massa para fazer com que as coisas que eu já estou acostumado no meu dia a dia e que garantem a entrega do meu código com qualidade funcionem. Também fiquei feliz de inesperadamente aprender mais sobre coisas que já faço todo dia de maneiras um pouco diferentes.

E você, já aprendeu algo de projetos simples?