Por Cheng Junior

No começo da minha carreira como engenheiro de software, utilizei alguns dos frameworks mais conhecidos da época para desenvolver em Java para WEB, como: Struts, Hibernate, JSF, Spring… Mesmo sem ter nenhuma noção de como uma aplicação WEB funcionava, essas soluções me ajudavam bastante, pois facilitavam a codificação e estabeleciam uma camada de abstração na qual eu não precisava me preocupar. Isso fazia com que eu conseguisse realizar entregas de uma forma bastante produtiva, mesmo com pouca experiência.

Após isso, eu mudei de empresa e comecei a trabalhar com Rails. Esse, até o momento (Dezembro de 2019), é o framework mais mágico que eu já conheci. Com quase nenhum código escrito, eu conseguia construir um sistema quase na sua completude. Com um comando, era possível criar um CRUD inteiro com tabelas SQL e telas em HTML.

Depois de alguns anos utilizando o Rails, chegou a hora de deixá-lo para trás e começar a utilizar a linguagem Golang. O Go é uma linguagem relativamente nova, similar ao C mas com memory safe, garbage collection, tipagem estrutural…

Neste momento, naturalmente, fui procurar junto com o time o “Rails” do Go. Existiam poucos disponíveis. Alguns simulavam o próprio Rails. No entanto, nenhum bom o suficiente para adotarmos. E aí eu me deparei com uma situação até então nova pra mim: desenvolver sistemas utilizando uma linguagem que não tem um framework bem estabelecido. Como será agora sem os Gandalfs e Dumbledores conjurando as magias para mim? A magia acabou!!

Foi aí que decidimos virar os feiticeiros. Criamos um framework em Golang completo: injeção de dependências, servidor HTTP (S), cache, gerenciamento de rotas… Após a primeira versão, aplicamos no primeiro projeto e jogamos em produção. A partir daí, tínhamos que manter o projeto e o framework. No andar do tempo, outras necessidades foram aparecendo e o esforço para desenvolver era enorme, pois tínhamos que codificar no projeto e no framework. Percebemos então que tínhamos criado um mostro… difícil de manter, com alto acoplamento, pouco flexível e com muitas funcionalidades desnecessárias!

Decidimos então dar alguns passos atrás, e começar do básico. O que eu preciso para construir meu sistema? Uma aplicação WEB precisa de um serviço HTTP e um conjunto de HTMLs. Simples, não? Então, criamos um projeto sem nada, nenhuma magia. Apenas utilizando a API nativa do Go. Daí, começamos a ganhar flexibilidade e o poder de customização.

Abrir tanto o código para o desenvolvedor pode aumentar o risco dele inserir bugs na arquitetura? Sim. Mas precisamos chamar a responsabilidade para nós, desenvolvedores. Possuir o conhecimento e o domínio do que está acontecendo ali é nossa obrigação. Faz a gente entender e nos dá a possibilidade de tomar decisões que nem sempre são as comuns. Nós, desenvolvedores, devemos ser John Wick, temos que puxar a responsabilidade pra nós e não deixar nas mãos de outras pessoas.

Mas e a segurança, onde entra? Uma das formas de se proteger é diminuindo a superfície de ataque. Neste caso, quanto menos código seu sistema tiver, menores as chances de bugs funcionais, como também, bugs de segurança (vulnerabilidades). Em outras palavras, quanto mais enxuto e menos libs o seu código utilizar, menos provável a presença de vulnerabilidades. Além disso, quando você possui total conhecimento e domínio sobre o código, no caso de surgir algum bug de segurança, você terá plenas condições de corrigi-lo. Agora, se você tiver utilizando alguma feitiçaria das pesadas, só quem vai corrigir são os feiticeiros. Daqui pra lá é 0-day. Se o feiticeiro for do tipo mestre dos magos, ou for alguma magia que tem poucos feiticeiros mantendo, o problema é ainda maior.

Ninguém quer reinventar a roda. Nem todo projeto tem a possibilidade de não utilizar algum framework. Mas, caso precise utilizar uma magia por motivos quaisquer que sejam, é necessário:

  • Ver se existe uma quantidade razoável de pessoas utilizando;
  • Ter um ótimo entendimento do seu funcionamento;
  • Estar sempre de olho nas atualizações;
  • Tentar ao máximo deixar atualizado;
  • Ver se ainda está sendo mantido e com uma frequência de atualizações boa, e;
  • Assinar listas de segurança que falam sobre esse framework.

Como o Golang tem uma API nativa muito rica, conseguimos desenvolver boa parte do que precisamos. Mas, mesmo assim, utilizamos pontualmente algumas libs de baixo acoplamento. Além disso, tentamos fazer com que todos do time entendam como é o fluxo de execução completo do sistema, dando o poder e a responsabilidade para todos do desenvolvedores.