Como estruturar WebApi em GoLang
GoLang nasceu tendo como premissa ser uma linguagem de programação simples e fácil de aprender. Porém não é pelo fato de ser uma linguagem simples que não nos devemos nos ater a forma em que estruturamos nossas aplicações em Go.
Quando pensamos em criar uma software para resolver algum determinado problema, além de nos atentarmos para os requisitos funcionais pelo qual descreve a necessidade da existência do software, temos também que nos atentar para como iremos estruturar nossa solução para que ela possa atender tais requisitos e possamos conseguir expressar o que o “negócio” demanda da solução por meio do nosso sistema a ser desenvolvido.
Estruturar uma aplicação pode ser comparado a uma arte, não existe uma forma correta de como fazer e muito menos uma única forma que atenda para todos os cenários. Com base nesta pequena introdução quero deixar aqui meu disclaimer. O intuito deste artigo é apenas apresentar uma simples proposta de como podemos estruturar uma aplicação GoLang utilizando alguns princípios de arquitetura de software para manter nossa solução com um baixo acoplamento e viabilizar a escrita de testes unitários.
Caso queiram conferir a implementação desta proposta podem acessar o Repositório.
O diagrama apresentado acima ilustra de uma forma geral a segregação das camadas da aplicação.
A camada Application é responsável pela regra de negócio de nossa aplicação, nesta camada é onde realizamos todas as operações para performar nossos casos de usos. Logo abaixo temos a camada Handlers essa camada é responsável por receber a requisição HTTP tratar o Body da requisição e aplicar as regras de negócio apropriadas para a requisição em questão. Na camada Presenter configura-se todas as regras de apresentação da nossa aplicação, neste caso a apresentação da nossa solução são rotas HTTP. E por fim a camada Infrastructure sendo responsável por manter nossa aplicação isolada de dependências externas. Na figura abaixo é apresentada uma possível implementação.
CMD
A pasta de CMD é um padrão da comunidade Go onde nela contém a configuração de startup de todos os processos do nosso projeto. Em alguns contextos podemos ter no mesmo projeto uma WebApi e uma processo batch que realiza um processamento em background, como por exemplo envio de emails. Desta forma o package CMD fica responsável por viabilizar a inicialização de todos estes processos.
PKG
A pasta PKG é um outro padrão da comunidade Go onde é inserido todos os pacotes que compõem nossa aplicação.
Considerações
Desenhar uma solução vai muito além de seguir a literatura à risca, para chegar em um melhor modelo para a solução deve ser levado em consideração vários requisitos funcionais e não funcionais mapeados através dos stakeholders. No repositório indicado acima resolvi não seguir à risca a proposta da Clean Architecture em alguns quesitos, um deles é de apenas a cama de Infrastructure deve conhecer os frameworks e bibliotecas externas. No projeto apresentado eu optei em acoplar a solução ao framework Gin, que hoje na atualidade é o framework mais utilizado para criação de WebApi, desta forma eu aceitei este acoplamento sabendo que os benefícios obtidos na simplificação do código foram muitos maior do que o acoplamento gerado.
Conclusão
GoLang é uma linguagem extremamente poderosa tendo uma sintaxe muito simples e uma compilação muito rápida, porém por estes benefícios facilmente podemos nos descuidar e criarmos soluções de forma desordenada e sem nenhum cuidado na estrutura da mesma. Atentar-se para a estruturação do projeto desde o início é uma boa prática que deve ser seguida sempre que possível juntamente com uma o princípio de arquitetura evolutiva.
Espero que tenha gostado deste rapido e simples artigo, estou a disposição para quaisquer dúvidas e também para receber criticas construtivas =)
