Padrão MVC senti falta de um comentário sobre ele. Eu mesmo, sigo em outras linguagem meio que o padrão do django, pois me acostumei, agora, estou criando uma plataforma: api em go e front em react, onde sigo a comunidade, ou seja: MVC, tá tudo bem, mas eu acho melhor o padrão Django.
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?
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
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.
@@JoaoVictorGuimaraesDeluchiTito 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.
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
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Anos como programador PHP e agora estou começando a estudar GO.
Anos com meu NodeJs mas aprender nunca é demais cá está eu aprendendo Golang com o Wesley, parabéns pelo conteúdo.
Adoro esse tipo de vídeo!
Padrão MVC senti falta de um comentário sobre ele. Eu mesmo, sigo em outras linguagem meio que o padrão do django, pois me acostumei, agora, estou criando uma plataforma: api em go e front em react, onde sigo a comunidade, ou seja: MVC, tá tudo bem, mas eu acho melhor o padrão Django.
Mega top: principalmente p/ mim que estou iniciando na GoLang
👍
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?
para esse caso não seria ideal usar o Workspace por conta de der o api-client e api-server?
Ficou muito bom
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)
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?
Essa pasta website, nela por exemplo eu poderia colocar um projeto angular é isso? Ou entendi errado...?
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?
@@JoaoVictorGuimaraesDeluchiTito
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
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 😅