Estruturando APIs em Go

Aplicando as melhores práticas para tornar seus projetos testáveis, de fácil manutenção ​​e entendimento

Transcript

1. Estruturando APIs em Go Aplicando as melhores práticas para tornar seus projetos testáveis, de fácil manutenção e entendimento
2. Jeferson Farias Calazans Software Developer http://calazans10.com @calazans10
3. Agenda • Tentar responder os seguintes questionamentos: • Devo manter todos os meus arquivos num único diretório e depois dividí-los? • Como devo dividir meu código e em quais pacotes? • Como devo estruturar minhas APIs em Go? • Por que alguns projetos têm um diretório cmd e qual é a vantagem disso? • Quais convenções devo adotar ao escrever código em Go?
4. Metas de uma boa estrutura
5. • Consistente • Fácil de entender, navegar e tem que fazer sentido • Fácil de mudar, fracamente acoplada • Fácil de testar • Design reflete exatamente como o software funciona • Estrutura reflete exatamente o design
6. Padrão de arquitetura
7. Clean Architecture
8. • Premissas • Independente de frameworks • Testável • Independente de UI • Independente de banco de dados • Independente de qualquer agente externo • Divide o código em quatro camadas • Entities: representam as entidades das regras de negócio • Use Cases: as regras de negócio da aplicação • Controller: adaptam e convertem os dados do formato usado pelas entidades e use cases para agentes externos como banco de dados, web, etc • Framework & Driver: frameworks e ferramentas como banco de dados, frameworks web, etc
9. Projeto exemplo
10. • Um serviço de avaliação de filmes: • Usuários podem adicionar um filme. • Usuários podem adicionar uma avaliação para um filme. • Usuários podem listar todos os filmes. • Usuários podem consultar o detalhe de um determinado filme. • Usuários podem listar todas as avaliações de um determinado filme. • Capacidade de adicionar alguns dados de amostra.
11. Flat
12. Layered
13. Modular
14. Standard
15. Convenções
16. • Testes • Mantenha os arquivos _test.go próximos aos arquivos principais. • Utilize um sub-pacote de mock compartilhado. • Nomenclaturas • Escolha nomes de pacotes que sugiram bem o que se pode esperar dentro. • Os pacotes devem comunicar o que eles fornecem, ao contrário do que eles contêm. • Evitar nomes genéricos como util, common, etc. • Siga as convenções habituais (https://talks.golang.org/2014/names.slide). • Evitar stutter (exemplo: strings.Reader não strings.StringReader)
17. Resumo
18. • Estrutura flat e simples é ok. • Dois diretórios de nível superior: • cmd (para os binários) e pkg (para os pacotes). • Dependências: pacotes próprios. • Mocks: sub-pacotes compartilhados. • Todos os outros arquivos (fixtures, resources, docs, Docker, …) ficam no diretório raiz do seu projeto • Pacote main inicializa e amarra tudo junto. E o arquivo main.go deve ser enxuto. • Evitar escopo global e funções init()
19. Conclusão
20. • Não existe uma estrutura correta, escolha a que melhor lhe atender. • “Seja como a água” • "Tudo deve ser o mais simples possível, mas não simplório." • Mantenha consistência • Experimente! • Compartilhe suas ideias
21. Perguntas? Links! • @calazans10 • Exemplos: https://github.com/calazans10/go-structure-examples • Slides: https://speakerdeck.com/calazans10/estruturando-apis-em-go • Referência: • The Clean Architecture por Robert C. Martin (Uncle Bob) • Clean Architecture using Golang por Elton Minetto • How Do You Structure Your Go Apps? por Kat Zień • Go best practices por Brian Ketelsen • Arquitetura Hexagonal por Camila Campos
22. Obrigado!