Golang: Como organizar pastas e arquivos em projetos Go

Рет қаралды 12,259

Жыл бұрын

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/golang-standards/p...
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.fullcycle.com.br/pag...
Saiba mais sobre o Curso Full Cycle. Agende um conato:
→ lp.fullcycle.com.br/lp-youtube

Пікірлер: 22

@christianpossidonio 4 ай бұрын

Anos com meu NodeJs mas aprender nunca é demais cá está eu aprendendo Golang com o Wesley, parabéns pelo conteúdo.

@dorianneto2859 11 ай бұрын

Adoro esse tipo de vídeo!

@leandrocosta3902 3 ай бұрын

Anos como programador PHP e agora estou começando a estudar GO.

@arozendojr Жыл бұрын

Ficou muito bom

@paulo.sistema 10 ай бұрын

Mega top: principalmente p/ mim que estou iniciando na GoLang 👍

@wagjr90 Жыл бұрын

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?

@guilhermemuradpim7317 2 ай бұрын

opa, muito obrigado 😁🙏! vc tem dicas de padroes ainda mais elaborados? (por exemplo pra dentros da pasta internal, coisas do dominio, migrations, etc)

@jogatinandodevs 7 ай бұрын

cmd eu uso src. não consigo me acostumar com cmd

@christianpossidonio 4 ай бұрын

No node eu tbm uso src e aqui o cmd achei bem estranho

@niltonmorais482 3 ай бұрын

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

@EdivaldoMerloStens 3 ай бұрын

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?

@FernandoLab 3 ай бұрын

Essa pasta website, nela por exemplo eu poderia colocar um projeto angular é isso? Ou entendi errado...?

@luciusstark Жыл бұрын

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.

@user-ho8gj1lx2v Жыл бұрын

No caso eu escreveria meu useCases no internal e meus controllers e clients no PKG?

@luciusstark Жыл бұрын

@@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.

@GchavesVDS 10 ай бұрын

@voguh__ 9 ай бұрын

Mano pq raios eles nao seguem um padrão simples de SRC e taca tudo la dentro?

@ustav_o Ай бұрын

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

@voguh__ Ай бұрын

@@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