Fiber v3: Redefining Go Web Frameworks with Migration Tools and the Services API

Apresentadora: Juliana Santos Convidado: Rafael Moreira (Engenheiro de Software Sênior e entusiasta do ecossistema Go) Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e é um prazer enorme ter vocês aqui com a gente em mais um episódio. Se você trabalha com desenvolvimento backend, sabe que o ecossistema Go não para um segundo, né? E hoje o assunto é quente: vamos falar sobre o Fiber. Apresentadora: Hoje eu recebo aqui no Allur o Rafael Moreira. O Rafael é Engenheiro de Software Sênior, trabalha com sistemas de alta escala e já vem testando o Fiber v3 desde as versões beta. Rafael, seja muito bem-vindo, cara! Massa demais ter você aqui. Convidado: Valeu, Juliana! O prazer é todo meu. Sou fã do Allur e falar de Go e Fiber é tipo meu passatempo favorito, então vai ser um papo bem legal. O Fiber v3 realmente mudou o jogo, cara, e eu tô ansioso pra gente destrinchar isso. Apresentadora: Show de bola! Rafael, vamos começar do começo. O Fiber v2 já era muito sólido, né? Muita gente usa em produção. Mas migrar de versão principal sempre dá aquele frio na barriga, tipo: "Lá vem as breaking changes e eu vou passar o final de semana corrigindo erro de compilação". Mas parece que a equipe do Fiber pensou nisso dessa vez com uma CLI nova, né? Como funciona esse `fiber upgrade`? Convidado: Pois é, Ju, você tocou na ferida! Migrar framework web costuma ser um parto, né? A gente abre aquele arquivo `CHANGELOG.md` imenso e começa a chorar (risos). Mas na v3 eles lançaram uma ferramenta de linha de comando que é sensacional. Em vez de você ficar caçando o que mudou, você roda o comando e a CLI analisa o seu código. Ela identifica métodos que foram renomeados, mudanças na estrutura dos handlers... e o mais legal: ela não só avisa, ela ajuda a refatorar. Apresentadora: Sério? Tipo, ela mexe no código por você? Convidado: Exato! Tipo assim, na v3 eles mudaram muita coisa interna de como os middlewares interagem com o ciclo de vida da requisição. Fazer isso na mão em um projeto com cem, duzentas rotas, seria um pesadelo. A CLI automatiza essa substituição de tipos e nomes de pacotes. Reduz muito aquele risco de você subir a versão e, do nada, um middleware parar de funcionar porque a assinatura da função mudou e você não viu. Pra quem tem sistema legado na v2, isso aqui é um divisor de águas, de verdade. Apresentadora: Nossa, isso economiza um tempo absurdo. Mas agora, falando de arquitetura... eu vi que a grande estrela dessa versão é a tal da "API de Services". Explica pra gente: o que mudou na forma como a gente gerencia dependências agora? Convidado: Cara, isso aqui é o meu ponto favorito. Na v2 e nas versões anteriores, o Fiber era meio "terra de ninguém" pra injeção de dependência. Ou você usava variáveis globais — o que é péssimo pra testar — ou você ficava passando struct de banco de dados pra cima e para baixo de um jeito meio bagunçado. Agora, na v3, eles introduziram o conceito de Services nativo. Apresentadora: Tipo um registro central de dependências? Convidado: Isso! Agora o Fiber tem um registro onde você "acopla" seus recursos. Imagina que você tem seu serviço de banco de dados ou um logger. Você registra ele no app do Fiber e, dentro do seu handler, você recupera ele direto do contexto. Mas a "sacada" não é só essa conveniência. O grande lance é o gerenciamento do ciclo de vida. Apresentadora: Como assim? Tipo o Graceful Shutdown? Convidado: Exatamente! Sabe quando você desliga o servidor e, se tiver uma query rodando, ela simplesmente "morre"? Com a Services API, o Fiber gerencia o shutdown ordenado. Ele sabe que precisa fechar os serviços antes de encerrar o processo. E pra quem faz teste unitário, ficou lindo. Você não precisa mais de gambiarra pra mocar o banco; você só registra um mock no service registry durante o teste e pronto. A lógica de negócio fica totalmente isolada da infraestrutura. É uma maturidade que o Fiber precisava muito. Apresentadora: Cara, que massa! Isso resolve uma das maiores críticas que o Fiber recebia, que era essa falta de um "padrão" mais empresarial, né? Agora, falando um pouquinho de código mesmo, eu li que o `fiber.Ctx` — que é o coração do framework — deixou de ser uma struct e virou uma interface. Pra quem tá ouvindo e talvez não seja tão bitolado na tipagem do Go, por que isso importa? Convidado: Boa pergunta! Parece um detalhe técnico bobo, mas muda tudo. Quando o `Ctx` era uma struct concreta, ele era "engessado". Se você quisesse estender as funcionalidades do contexto ou criar um wrapper customizado, era bem difícil fazer isso sem perder a performance que o Fiber entrega. Ao transformar em interface, o framework ficou muito mais flexível. Agora o time do Fiber consegue entregar diferentes implementações de contexto dependendo do caso de uso. E pra quem cria biblioteca e middleware pro Fiber, ficou muito mais fácil interceptar e decorar o contexto com novas funcionalidades. Apresentadora: E mesmo com essas abstrações todas — interfaces, serviços, injeção — ele continua sendo rápido? Porque o medo da galera é: "Ah, colocou muita camada, agora vai ficar pesado". Convidado: (Risos) Pode ficar tranquila, Ju! O Fiber continua sendo o Fiber. Eles são obcecados por performance. Eles continuam usando pools de objetos de forma agressiva. A diferença é que agora o motor tá mais "inteligente". Outra coisa legal é a conformidade com as RFCs do HTTP. Eles refinaram o tratamento de headers e códigos de status. Isso significa que, se você colocar seu app Fiber atrás de um Nginx, um Envoy ou rodar em Edge Computing, ele vai se comportar de forma muito mais previsível. É o que eu digo: o Fiber v3 parou de ser só um "carro de corrida" pra ser um "carro de corrida de luxo", sabe? Rápido, mas com toda a segurança e conforto pra quem pilota. Apresentadora: Adorei a analogia! É tipo aquele momento onde o projeto deixa de ser um experimento veloz e vira uma solução de mercado, né? Rafael, se alguém tá ouvindo a gente agora e tem um projeto em Fiber v2, qual o seu conselho? Migra agora ou espera um pouco? Convidado: Cara, o meu conselho é: comece a testar hoje em ambiente de staging. A v3 já tá estável. Baixa a CLI, roda o `fiber upgrade` num branch separado e vê como seu código se comporta. A documentação nova tá muito boa, tem guias de migração bem detalhados. Se você sofre com gestão de dependência ou quer um código mais limpo e testável, a v3 é um upgrade obrigatório. Não tem por que ficar pra trás, a DX (Developer Experience) está em outro nível. Apresentadora: Sensacional! Bom, chegamos ao fim de mais um papo incrível aqui no Allur. Rafael, obrigada demais por compartilhar seu conhecimento e essa empolgação com o Fiber v3. Foi massa demais! Convidado: Eu que agradeço, Juliana! Valeu pelo convite e parabéns pelo podcast, o conteúdo de vocês é de primeira. Até a próxima! Apresentadora: Valeu! E pra você que acompanhou a gente até aqui, as principais conclusões de hoje são: o Fiber v3 amadureceu, a migração tá mais fácil do que nunca com a nova CLI e a Services API veio pra organizar de vez a arquitetura dos nossos apps em Go. Se quiser saber mais, dá uma olhada no site oficial do Fiber (gofiber.io), a documentação tá tinindo!