Após construir um site com uma arquitetura completa por conta própria, sinto que evoluí como desenvolvedor. Não é apenas sobre escrever código, usar letras coloridas ou adotar as tecnologias mais modernas (aquelas que todos acham legais no mundo do desenvolvimento). É sobre a arquitetura que escolhi, as decisões que tomei, o tempo que investi e os desafios que enfrentei ao longo do caminho.

Ao longo do caminho, precisei fazer diversas escolhas para conciliar o "o que eu quero fazer" com o "o que eu consigo fazer". São as limitações que pesam nossas escolhas.

Construir esse site do zero até o deploy abriu meus olhos para o vasto mundo do desenvolvimento de software, que vai muito além de apenas escrever Código Limpo. É sobre pensar cinco passos à frente e encontrar o equilíbrio entre o que é desejável e o que é realmente alcançável.

Escolhendo meus Objetivos

Antes de escolher entre um provedor de cloud X ou Y, eu precisava entender claramente o que realmente queria para o meu site. Seria apenas uma página "Sobre Mim"? Um blog? Qual o propósito que quero alcançar? Essas foram apenas algumas das muitas perguntas que precisei responder antes de começar a pôr a mão na massa.

Depois de muita reflexão, entendi finalmente o que eu realmente queria: um espaço onde eu pudesse publicar todo tipo de conteúdo, artigos, fotos ou até pensamentos aleatórios. Eu queria um lugar onde pudesse ser eu mesmo, compartilhar minhas ideias, opiniões, reflexões e até alguns tutoriais.

Porém, não queria algo formal e polido, onde tudo o que eu escrevesse tivesse que ser perfeito e imutável, queria um espaço que fosse dinâmico, passível ao erro, com ideias novas e sem o peso de ter que entregar algo perfeito.

No final do dia, eu queria um lugar meu, para ser utilizado ao decorrer da minha vida, onde eu sempre tivesse algo para fazer, e não um projeto morto, que se faz uma vez e nunca mais se toca. Esse é o motivo de eu ter preferido criar um site do zero do que simplesmente criar uma página no Medium.

Prototipação

Agora que eu tinha refletido sobre o que queria alcançar, comecei a transformar minha visão em realidade. Entrei no Figma (uma ferramenta gratuita para protótipo de sites) Com um monte de ideias e pensamentos girando na minha cabeça, criando diagramas de como deveria ser a página inicial, a estrutura de um post e as possíveis ações disponíveis para os usuários.

Mesmo fazendo um protótipo tenho que ser sincero! Eu não copiei e colei o que estava lá, nem mesmo alterava no protótipo qualquer mudança que eu fizesse no site. Como você pode ver na imagem abaixo, algumas coisas estão um pouco diferentes de como realmente está o site, como o modo claro da página principal.

Protótipo do Figma

Passei por várias fases de prototipagem, ajustando as coisas aqui e ali até que tudo estivesse alinhado com o que eu tinha em mente. O Figma foi realmente um divisor de águas para transformar aquelas ideias abstratas em algo que eu pudesse ver e me divertir.

Escolha das tecnologias

Antes de codar foi necessário tomar a principal decisão que qualquer desenvolvedor adora tomar, se eu pudesse chutar, é a escolha que a maioria dos desenvolvedores mais gosta de fazer, qual linguagem de programação escolher? Existem muitos tipos de pessoas quando se trata dessa decisão, alguns vão pelo hype, outros por comodidade e outros são mais céticos e procuram decidir com base em dados qual a melhor ferramenta para resolver o problema.

Desenvolvimento Front-end

Para o front eu escolhi usar TypeScript, não vou mentir, a escolha de TypeScript foi quase toda baseada em Hype. Como eu já tinha um pouco de experiência com JavaScript e sempre via gente falando muito bem de TypeScript, decidi me desafiar e ir com essa escolha. Não fiquei nada receoso com o fato de ser fortemente tipado, até porque as linguagens que mais utilizo no dia a dia são Java e Kotlin, então isso não seria um grande problema.

Desenvolvimento Back-end

Para escolher a linguagem para o Back-end pensei em 3 caminhos

Ir com o que já sei
- Facilitaria o desenvolvimento por já estar acostumado com a linguagem, no caso eu pensei em Kotlin ou Java.
Hype e aprender algo do 0
- Seria divertido aprender algo novo, é sempre gostoso codar em uma linguagem totalmente nova.
Utilizar a mesma linguagem do front-end
- Facilitaria o desenvolvimento conjunto conseguindo rodar apenas um projeto para trabalhar.

No final eu escolhi a primeira opção, fui com Kotlin, decisão essa que me custaria um preço alto mais na frente.

Database

Reconhecendo o sucesso dos bancos de dados No SQL em aplicações de blog, particularmente o MongoDB, optei pelo MongoDB Atlas, atraído pelo seu plano gratuito acessível. Além de já ter trabalhado com a ferramenta.

No entanto, para armazenar imagens e conteúdo de postagens, busquei uma solução diferente. Com base na experiência, recorri ao Amazon S3 para o armazenamento de imagens, garantindo uma solução robusta e escalável para o gerenciamento de arquivos de mídia. Consequentemente, a AWS surgiu como o provedor de nuvem preferido, dada sua integração perfeita com o Amazon S3 e o conjunto abrangente de serviços que oferece.

Problemas

Depois de muito esforço, lancei finalmente o projeto em produção, usando o Vercel para hospedar o site. No entanto, como escolhi uma linguagem "pesada" para o back-end, as soluções de hospedagem na modalidade free-tier não funcionavam de forma satisfatória. O resultado? Uma navegação extremamente lenta, com requisições ao back-end demorando cerca de 10 segundos. Dez segundos para carregar uma página é inaceitável, especialmente porque este site carrega o meu nome, e eu quero entregar uma experiência de qualidade.

/

Além disso, enfrentei outro grande desafio: o OpenGraph. Se você não conhece, o OpenGraph é o que permite, por exemplo, que ao compartilhar um vídeo do YouTube no LinkedIn, um card atraente com a pré-visualização do conteúdo seja exibido. Como o meu site terá vários artigos, eu queria que ao compartilhar o link aparecessem o título do artigo e a thumbnail. Sem isso, os links ficariam sem graça e pouco chamativos, o que seria uma grande falha.

/

Quando você vê um vídeo muito legal no YouTube, e deseja compartilhar nas suas redes sociais como o LinkedIn, por exemplo, coloca o link do vídeo e aparece um card muito legal, mostrando a pré-visualização do conteúdo, bom, isso é o que o OpenGraph faz. Como no meu site terei vários artigos, na hora de compartilhar queria que mostrasse o título do artigo e a thumbnail por que se não tivesse isso, os links iam ficar extremamente sem graça e nada chamativo, seria uma falha muito grande.

/

Você deve estar pensando: "Resolver isso deve ser fácil, certo?" E é, desde que eu tivesse feito escolhas melhores no passado. O OpenGraph funciona em sites renderizados do lado do servidor (SSR). Mas eu havia desenvolvido todo o site para ser renderizado do lado do cliente (CSR). Em resumo, precisei refazer quase tudo: tirei o back-end da JVM (Kotlin) e adotei um framework de front-end que suportasse a renderização do lado do servidor. Para isso, precisei migrar meu projeto de CRA para Next.js.

/

Agora, se você, leitor experiente, está se perguntando "Mas por que você não fez...?", a resposta é simples: falta de conhecimento. Minhas pesquisas me levaram a acreditar que essa era a melhor solução. Pode haver outras formas de resolver o problema; eu vi algumas alternativas, mas essa parecia a mais adequada para o longo prazo.

/

No final, percebi que não precisava de tudo o que havia planejado. Não precisava de um banco de dados separado, nem de um servidor ou um back-end independente. Com alguns serviços, como o S3 e outras ferramentas oferecidas pela Vercel, já consegui entregar um resultado de qualidade, exatamente como eu queria.

Afinal de contas valeu a pena?

Sim, vale a pena!

Não me arrependo de nada. Apesar de ter tomado várias decisões erradas e de passar muitos finais de semana refatorando código, no fim das contas, construí exatamente o que eu queria: um espaço meu, com a minha identidade.

Acho que foi importante ter criado uma aplicação full-stack do zero. Sentir na pele o que é construir um projeto sozinho, onde, se algo der errado, a responsabilidade é minha, mas, se der certo, o mérito também. Estou muito orgulhoso de ver o site funcionando e de poder dizer com confiança: "Fui eu quem fiz.”

No final das contas, é isso que importa: sentir-se bem com o que você criou.

Pode parecer que estou falando como se o projeto estivesse "finalizado", mas a verdade é que ele apenas começou. Este projeto está vivo e não vai desaparecer tão cedo. Agora é o momento de realmente agregar valor, escrevendo sobre o que penso e atualizando constantemente a página "Globo", onde compartilho os lugares que já visitei.

A maior lição que aprendi com o desenvolvimento do projeto foi KISS 💋.

Se você quiser ver o código do Site, como ele é por debaixo dos panos, para se inspirar, julgar, ou apenas por curiosidade, sinta-se livre, e por favor, se gostou, não se esqueça de dar uma estrela ⭐, me faz muito feliz! GitHub

O que mudou no Clean Code após AI