Assumindo que você leu o meu post Iniciando um Projeto Go você deve ter o ponto de partida para um serviço web mínimo go. Para o seu primeiro projeto é mais fácil manter todo o seu código em uma pasta, na base do seu projeto, mas em algum momento você vai querer reestruturar as coisas, isso é feito por algumas razões:
- Devendo tudo em uma pasta resulta em muitas inter-dependências no código.
- Reusar fora do projeto pode ser difícil, pois o código foi projetado para ser usado apenas em um pacote.
- É impossível ter mais de um binário, pois você pode ter apenas um método
main.
Este post irá fornecer uma visão geral da estrutura que eu sigo nos meus projetos Go ao construir serviços web.
Note: Se você está apenas construindo uma biblioteca para usar nos seus serviços, ou compartilhar com outros, não há problema em colocar tudo na pasta base do seu projeto, um exemplo disso é a minha biblioteca dynastore.
/cmd
Esta pasta contém os principais arquivos de ponto de entrada do aplicativo para o projeto, com o nome do diretório correspondente ao nome do binário. Assim, por exemplo cmd/simple-service significando que o binário que publicamos será simple-service.
/internal
Este pacote contém o código da biblioteca privada utilizada no seu serviço, ele é específico para a função do serviço e não é compartilhado com outros serviços. Uma coisa a notar é que esta privacidade é imposta pelo próprio compilador, veja as notas de lançamento do Go 1.4 para mais detalhes.
/pkg
Esta pasta contém código que é OK para outros serviços consumirem, isto pode incluir clientes API, ou funções utilitárias que podem ser úteis para outros projetos, mas não justificam seu próprio projeto. Pessoalmente eu prefiro usar isso em vez de internal, principalmente porque gosto de manter as coisas abertas para reutilização na maioria dos projetos.
Estrutura do projeto
Como você constrói seu projeto há alguns objetivos muito importantes que você deve considerar quando se trata de como você estrutura seus pacotes:
>
- Coisas consistentes
- Coisas o mais simples possível, mas não mais simples
- Só duas seções do serviço ou aplicação
- Ajuste para assegurar que é fácil navegar em seu caminho
>
Over tudo ao começar você deve experimentar um pouco, experimentar algumas idéias diferentes ao construir seu primeiro e obter algum feedback com base nos objetivos acima.
O objetivo número um é você construir um software fácil de manter, consistente e confiável.
Exemplo
Eu recomendo dar uma olhada no exitus para ver como eu estruturo meus projetos, a maior parte do código está sob a pasta pkg com cada sub-pasta tendo um ou mais arquivos. A partir do nível superior é bastante claro com o que cada pacote se relaciona, e apesar de se apoiar em testes, ele tem alguns exemplos.
$ tree exitus/ exitus/├── cmd│ ├── authtest│ │ └─── main.go│ ├─│─ backend│ ─ └── main.go│ └─ client│ └─ main.go├─ dev│ ├─ add_migration.sh│ └─ docker-compose.yml├─ Dockerfile├─ go.mod├─ go.sum│ ├─ 20190721131113_extensions.down.sql│ ├─ 20190721131113_extensions.up.sql│ ├─ 20190723044115_customer_projects.down.sql│ ├─ 20190723044115_customer_projects.up.sql│ ├─ 20190726175158_issues.down.sql│ ├── 20190726175158_issues.up.sql│ ├─ 20190726201649_comments.down.sql│ ├─ 20190726201649_comments.up.sql│ ├─ bindata.go│ ├── migrations_test.go│ └─ README.md├── pkg│ ├─ api│ │ ├─ exitus.gen.go│ │ ├─ exitus.yml│ │ └─ exitus.yml│ ─ └─ gen.go│ ├│─ auth│ ─ ├─ scopes.go│ └─ user.go│ ├─ conf│ │ ─ ├│ conf.go│ ─ └─ conf_test.go│ ├─│ db│ ─ ├│ db.go│ ─ ├│ dbtesting.go│ ─ ├─│ migrate.go│ ─ ├─│ sqlhooks.go│ ─ └─ transactions.go│ ├─│ env│ ─ └─── env.go│ ├─ healthz│ │ ─ ├│ healthz.go│ ─ └── healthz_test.go│ ├─│ jwt│ ─ └─── jwt.go│ ├│─ metrics│ ─ └── metrics.go│ ├│─ middleware│ ─ └── middleware.go│ ├─ oidc│ │ └ └── client.go│ ├── server│ ├─ reflect.go│ └─ server.go│ store│─ store│ ├── comments.go│ ├── comments_test.go│ ├─ customers.go│ ├─ customers_test.go│ ├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ └─ store.go└── README.md
O objectivo aqui é ilustrar como você faz crescer o seu projecto de um par de ficheiros, para um serviço web maior. Encorajo-o a pesquisar os projectos do github e a investigar como outros criadores estruturaram os seus, e acima de tudo experimente você mesmo!
- GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
- Standard Go Project Layout
- GopherCon 2018: Cat Seeing – How Do You Structure Your Go Apps
Feedback
Feel free to reach out via:
- @ me no Twitter
- Envie-me um Email
- Começar um Projecto Go
- Construir um carro burro WLToys A979
- Começar com Cognito?
- Porquê CDK?
- Trabalhos de fundo sem servidor parte 2