Golang: Como organizar pastas e arquivos em projetos Go
Vložit
- čas přidán 12. 09. 2024
- Aprenda de uma vez por todas a como organizar seus projetos com arquivos e pastas seguindo o padrão da comunidade Go.
Link para Go Standards: github.com/gol...
Entre os dias 17 a 19 de Julho vai rolar o Go Intensivo, um evento 100% gratuito e online para você que quer desenvolver aplicações de alta performance com Go.
→ Participe: goexpert.fullc...
Saiba mais sobre o Curso Full Cycle. Agende um conato:
→ lp.fullcycle.c...
Anos com meu NodeJs mas aprender nunca é demais cá está eu aprendendo Golang com o Wesley, parabéns pelo conteúdo.
Esse vídeo é bom demais. Espero que tenha sobre outras linguagens tbm!!
Adoro esse tipo de vídeo!
Anos como programador PHP e agora estou começando a estudar GO.
Vídeo simples e muito útil, me deparei com essas 'controvérsias' também um tempo atrás.
Qual sua opinião quanto ao local de um package 'i18n' no projeto?
Quanto mais vejo essa bagunça, mais gosto do Java. Pq o Node e outras linguagens não copiam o método Maven para organizar dependências?
Mega top: principalmente p/ mim que estou iniciando na GoLang
👍
cmd eu uso src. não consigo me acostumar com cmd
No node eu tbm uso src e aqui o cmd achei bem estranho
eu tbm achava estranho, por vim do node eu preferia utilizar src.. mas depois que comecei a trabalhar no mercado livre me acostumei com o cmd e internal, pq lá o scaffolding de aplicações go são gerados exatamente assim com essa estrutura
opa, muito obrigado 😁🙏! vc tem dicas de padroes ainda mais elaborados? (por exemplo pra dentros da pasta internal, coisas do dominio, migrations, etc)
Ficou muito bom
Lembrando que essa estrutura não é uma convenção oficial da linguagem. Utilizo o mais simplista porque, por ora, não me enquadro nos casos que precise utilizar diretórios mais complicados. Uso:
cmd - prog entrypoint;
config(s) - no singular mesmo - o "s" existe quando tem mais de um arquivo, assim segue para os outros;
internal - para os módulos internos como "middleware e core";
pkg - pelo mesmo motivo, funciona como uma biblioteca;
docs - documentação de tudo, incluindo para mim, documentando as ideias durante o desenvolvimento;
example(s) - demonstração de como usar os recursos do "/pkg";
asset(s) - para imagens em geral.
Raramente uso:
Makefile;
/script(s);
/deployment(s);
Nesta mesma ordem. O Makefile só existe se houver "/scripts" ou "/deployments". Em muitos casos, quando o deployments está presente, também existe o diretório scripts. Aquela mania de querer automatizar tudo para funcionar num clique só.
Já criei APIs Rest e gRPC, mas como não foi para ambiente corporativo, não usei swagger e costumo ficar somente no Postman mesmo.
No caso eu escreveria meu useCases no internal e meus controllers e clients no PKG?
@@user-ho8gj1lx2v
Considerando que o "useCase" é somente código interno para o funcionamento crucial da aplicação e não ser usado como "API" exposta para outros que queiram usar para efetuar algum tipo de integração, então, sim; seu useCase pode residir no diretório "internal". Em contrapartida, o "controllers" e "clients" como PKG sem explicar o que são, fica estranho confirmar se eles ficariam no PKG porque esses mesmos nomes, especialmente, o "clients" parece nome da parte "client" da aplicação, que normalmente fica em "cmd/client" e o "controllers" parece ser algo relacionado ao "internal".
O "controllers" e "clients" apenas seriam parte do PKG se o deles servirão para projetos externos/terceiros interagirem. Por outro lado, eles poderiam fazer parte de PKG no contexto que "controllers" é o componente que lida com as solicitações recebidas, as processa e retorna uma resposta; o clients, a interface que interage com um ou mais servidores/serviços externos.
Entretanto, o nome "controllers" para PKG soa estranho dependendo do cenário tradicional de desenvolvimento. Por exemplo, com base no MVC (Model-View-Controller), o termo "controllers" é frequentemente usado conforme foi explicado anteriormente. Porém, quando pensado em contexto de uma biblioteca Go que será importada por outros pacotes (propósito de "pkg"), o nome "controllers" pode não ser o termo mais intuitivo. Isso ocorre porque - normalmente - os controladores estão acoplados à lógica específica do aplicativo e não são projetados para serem reutilizados por outros pacotes/projetos. O nome "clients" é ambíguo, então, de certa forma, tudo bem; embora, se "user" ou "users" fizer sentido no seu cenário, recomendo optar por estes.
Eu
Essa pasta website, nela por exemplo eu poderia colocar um projeto angular é isso? Ou entendi errado...?
Mano pq raios eles nao seguem um padrão simples de SRC e taca tudo la dentro?
qual o problema de usar cmd ao invés?
é uma convenção utilizada pela comunidade, quando for trabalhar com essa linguagem com certeza vai ser dessa maneira. não custa nada aprender as melhores práticas
@@ustav_o costume, todas as linguagens que usei sempre tem uma src ou uma pasta específica onde todo o código está e a raz normalmente fica só um arquivo de config e tals
CMD e a pasta API sempre me trollam, eu sempre começo procurando o código na pasta api... porque estou procurando o códig da api .-. kkkkk
Eu tbm fui trollado kk
Resumo…. Mais ou menos mais ou menos 😅