Já posso ouvir os puristas do Go afiando seus forcados. “Use a biblioteca padrão”, eles entoam. “Frameworks são um antipadrão”, eles gritam.
Eu não me importo.
Não estou usando Fiber porque sou preguiçoso. Não estou usando porque se parece com o Express.js. Estou usando porque tenho um vício patológico por velocidade, e o net/http, abençoado seja seu coração seguro e compatível, é simplesmente educado demais para a violência que quero infligir na minha CPU.
Preciso desabafar. Algo que tem apodrecido na minha alma desde a primeira vez que entrei em um projeto em meio ao desenvolvimento e fiz a pergunta fatídica: “Onde está a documentação da API?”
A resposta, invariavelmente, era uma das seguintes:
“Confira a coleção do Postman.” (Tradução: um cemitério de 200 requisições, metade das quais desatualizadas, com nomes como GET users FINAL v2 (cópia))
“É só olhar o código.” (Tradução: faça engenharia reversa do nosso espaguete e boa sorte)
“Vamos documentar depois.” (Tradução: nunca vamos documentar)
Vou começar este post com uma confissão que pode me render alguns inimigos: Eu odeio JSON.
Não é um ódio irracional, daqueles que aparecem do nada. É um ódio construído, tijolo por tijolo, ao longo de anos debugando payloads malformados, campos que deveriam ser números mas chegaram como strings, e aquele clássico null onde você esperava um array vazio. JSON é o equivalente digital de uma conversa telefônica com sua avó: você acha que entendeu o que ela disse, mas quando você chega lá, o bolo de cenoura não tinha aquela cobertura de chocolate esperada (brasileiros vão entender).
Para quem pulou as aulas da Academia da Frota Estelar, o Kobayashi Maru é um exercício de treinamento projetado como um “cenário sem vitória”. O objetivo não é vencer, é ver como você lida com uma falha inevitável. No mundo da Engenharia de Backend, nosso cenário sem vitória é a Exceção Não Tratada.
Você passa semanas arquitetando um serviço bonito e limpo. Você usa Records, otimiza suas consultas SQL, aplica princípios SOLID. E então, no dia da produção, um usuário envia um JSON malformado, e sua API vomita um Stack Trace de 50 linhas diretamente no console do navegador dele. É feio, é pouco profissional e expõe sua lógica interna para o mundo.
Se você é um desenvolvedor que já lidou com processamento de folha de pagamento ou conciliação bancária/financeira em uma empresa que usa Spring, provavelmente já trabalhou com Spring Batch. Confesso que não sou um grande fã; ele tem aquela característica verbosidade e sobrecarga do ecossistema Java, fazendo parecer que até o job mais simples exige muito mais estrutura do que o necessário. Mas de que adianta reclamar? A tecnologia que sua empresa usa é o que garante sua sobrevivência (moradia, comida, roupa). Então, lamentações não são o tema de hoje.
