Bom demais @gatogordo, que bom que ajudou! Os próximos dois vídeos do canal (segunda dia 30/set e próxima segunda dia 7/out) vão dar mais dicas compatíveis com CQRS. Estou montando um projeto base que está crescendo pra usar CQRS, veja se é relevante pra vc. Valeu!
Hehe, aí sim hein! 😅 Vou fazer uma séria completa de NestJS "na faixa" pra galera, e aí depois a gente pensa num conteúdo mais avançado pra lançar como curso. Obrigado pela força, Dias!
me candidatando pra vagas junior como desenvolvedor acabei me deparando com mais essa sigla, achei muito legal a arquitetura e meio estranho escrever a própria query pra ser executada, fiquei pensado se em algum caso esse tipo de abordagem seria melhor que usar um graphql em todo caso é mais um aprendizado e vou voltar aqui sempre que precisar implementar esse tipo de arquitetura.
Fala aí Lourivan, bom demais? Optei por escrever SQL direto em vez de usar o repositório ou query builder do TypeORM principalmente por performance e controle. Fazer consultas manuais é uma prática comum, porque permite otimizar de forma mais precisa, especialmente quando vc está lidando com queries complexas que precisam ser bem eficientes, evitando o overhead que a abstração do ORM pode trazer. O graphQL cai no mesmo caso; ele traz conveniência ao custo de performance; sempre rola essa troca em programação. Então na verdade depende do objetivo da funcionalidade que você está desenvolvendo. Se quiser dar conveniência para quem consome uma API, graphQL é rei mesmo; agora, se estiver otimizando pra performance, nada vai bater uma query escrita manualmente para aproveitar os índices do banco de dados. Obrigado pelo comentário e por ter assistido ao vídeo. Sucesso!
Obrigado, Danrllei 🤝 Vou fazer um sobre DDD sim, e penso até que serão alguns vídeos dedicados ao assunto, pq DDD de verdade é um negócio que exige profundidade, se não for pra fazer apenas um "DDD-light" né... mas eu sou fã de DDD, vou fazer sim :) valeu pelo incentivo!
Boa pedida! Eu pessoalmente acho Event Sourcing difícil de acertar, mas o DDD é uma grande paixão minha. Então aceito o desafio, só não posso prometer data. Valeu pela sugestão!
Fala aí George, obrigado! Eu acho super válido utilizar o Prisma, ou qualquer outro ORM que você domine e atenda às suas necessidades. Eu uso o TypeORM pelo mesmo motivo: ele atende às minhas necessidades e sei como usá-lo; não vejo motivo para me aprofundar em outro ORM que, grosso modo, faz a mesma coisa, ainda mais sabendo que tem tanta coisa ainda pra estudar 😅 Mas reforço: se ele te atende e você manja, continue com ele, vai dar certo.
Parabéns pelo conteúdo excelente! Tenho uma dúvida sobre a organização do código. Gosto da ideia de agrupar todos os recursos relacionados em um mesmo lugar, como você faz. Mas como você lida com situações em que outras queries precisam de um recurso específico, como o employee.dto, por exemplo?
Fala Flavio, ótima pergunta! Eu costumo começar colocando o DTO junto com a própria query e, conforme vai sendo necessário, vou movendo ele gradativamente para níveis mais externos na estrutura. Acho que a estrutura de arquivos e pastas do projeto não deve ser rígida; ela deve evoluir conforme o projeto cresce e à medida que nosso entendimento sobre o problema ou negócio que estamos resolvendo também evolui. Por exemplo, no início eu colocaria a classe de DTO no mesmo arquivo da query, dependendo do tamanho do projeto e da equipe. Depois, poderia mover para um arquivo ".dto.ts" dentro da pasta /employees/queries. Mais adiante, pode ser interessante criar uma pasta /employees/dtos se você tiver muitos DTOs compartilhados dentro do contexto de employees. E, por fim, pode acabar em uma pasta /shared ou /common, acessada pelo contexto de employees e outros, conforme a necessidade. Uma coisa importante é tomar cuidado com o acoplamento. É péssimo para o projeto quando você começa a adicionar propriedades ao DTO que não fazem sentido para todas as queries/contextos que o usam. Por exemplo, digamos que o DTO começa com id e name. Você compartilha ele, e depois adiciona um dateOfBirth: Date que só faz sentido para algumas queries. Então você deixa dateOfBirth como Date | null. Mas atenção: uma coisa é deixar algo como nullable porque o dado é usado em todas as queries mas pode ser null, e outra coisa é deixar null porque só algumas queries precisam dele. Quando chega nesse nível de acoplamento, é melhor não compartilhar. Prefira duplicar código a criar um acoplamento desnecessário, que só vai te trazer dor de cabeça no futuro. Espero que isso ajude! Abraço!
Fala Phill, tá sumido mestre? Tudo bem por aí? Cara esse mês entrei numa startup dos USA pra trampar como fullstack e lá eles usam Nestjs no backend ... estou até retornando pra ver esses vídeos aqui da sua série... mande notícias, valeuu
Fala aí Rock, tudo bom? Obrigado demais pela mensagem, man 👊 tá tudo certo sim; passei um período com uma gripe forte, o bicho pegou, mas agora estou de volta. Tem uma questão de conciliar tempo do trabalho com o canal, afinal eu faço os vídeos no meu tempo livre, muitas vezes no fim de semana, e quando a coisa aperta no trabalho o canal sofre, hehe, mas vamos aí, a ideia é continuar.
E que legal que você está usando NestJS no trabalho. Se topar, me add no linked-in e a gente marca um papo qq dia desses pra trocar experiências. Sucesso pra você no novo desafio!
Dá sim, com certeza, mas vai dar um certo trabalho, porque o ExpressJS não dá suporte nativo pro CQRS assim como o NestJS. Você vai precisar estruturar tudo manualmente. Dá uma olhada em pacotes npm como cqrs-domain pra gerenciar comandos e eventos de domínio, e o cqrs-lite pra um framework CQRS mais leve. Como opinião pessoal, eu considero o NodeJS puro ou o ExpressJS bons para projetos pequenos e sem muita complexidade; eles são leves e não te direcionam nem te forçam a fazer as coisas de uma forma específica. Pra projetos grandes e/ou complexos, eu acho ruim porque você perde produtividade ou perde em boas práticas, porque você tem que implementar muita coisa manualmente, ou conhecer bem os pacotes que ajudam na implementação que quer fazer, e se não estiver bem afiado nos padrões que quer aplicar, o risco de meter o pé pelas mãos é grande. Foi por isso que virei fã do NestJS. Ele é opinionado e traz muita coisa pronta; isso tem seus pontos fracos, mas não se discute produtividade. Você voa!
Resolvi complementar a resposta pra dizer o seguinte: pra todo e qualquer padrão ou "boa prática", é sempre possível (e recomendado) você entender bem qual é a FILOSOFIA do padrão. Qual problema ele resolve, por que o problema aparece, e como a solução foi estruturada. A partir disso, você vai conseguir (re)implementar uma versão do padrão que seja apropriada para o seu caso de uso específico. De forma bem simples, se você implementar cada query e comando numa classe separada, implementando uma determinada interface ou classe base, e chamar essa classe no seu controller, você já vai chegar no mesmo lugar do que eu apresentei no vídeo, sem complicar e sem instalar nenhum pacote. Por isso reforço: é importante entender bem qual problema você está tentando resolver e qual parte do padrão resolve isso; daí fica fácil aplicar.
@@PhillCode que legal, eu ja estou proximo de focar no estudo do Nest. pelo visto vai ser muito util e produtivo. Eu estudei bastante o node.js por muito tempo e junto com isso ainda tive que passar muito tempo estudando javascript e uma marretada de outras coisas relacionadas a frontend com react, nextjs e etc... kkkk. Uma pergunta, com este Nest eu ja tenho classes prontas para fazer CQRS, Saga, e DDD, websocket e tudo isso ne? Vc tem cursos que ensina com contexto a essas tecnologias?
Hi! I'm sorry to hear that... but I think there's a lot of great content available in English and other languages already. So, I've chosen to focus on bringing some of that to Brazil, in Brazilian Portuguese. Perhaps in the future, I can explore providing translations or captions :)
Oloco, muito bom!!!
Carai! Perfeito, tô trabalhando exatamente nisso.
Bom demais @gatogordo, que bom que ajudou! Os próximos dois vídeos do canal (segunda dia 30/set e próxima segunda dia 7/out) vão dar mais dicas compatíveis com CQRS. Estou montando um projeto base que está crescendo pra usar CQRS, veja se é relevante pra vc. Valeu!
Já pode lançar o curso Phill, to com o cartão na mão 😆
Que didatica fantástica! Rapido, direto e objetivo
Hehe, aí sim hein! 😅 Vou fazer uma séria completa de NestJS "na faixa" pra galera, e aí depois a gente pensa num conteúdo mais avançado pra lançar como curso. Obrigado pela força, Dias!
me candidatando pra vagas junior como desenvolvedor acabei me deparando com mais essa sigla, achei muito legal a arquitetura e meio estranho escrever a própria query pra ser executada, fiquei pensado se em algum caso esse tipo de abordagem seria melhor que usar um graphql em todo caso é mais um aprendizado e vou voltar aqui sempre que precisar implementar esse tipo de arquitetura.
Fala aí Lourivan, bom demais? Optei por escrever SQL direto em vez de usar o repositório ou query builder do TypeORM principalmente por performance e controle. Fazer consultas manuais é uma prática comum, porque permite otimizar de forma mais precisa, especialmente quando vc está lidando com queries complexas que precisam ser bem eficientes, evitando o overhead que a abstração do ORM pode trazer.
O graphQL cai no mesmo caso; ele traz conveniência ao custo de performance; sempre rola essa troca em programação. Então na verdade depende do objetivo da funcionalidade que você está desenvolvendo. Se quiser dar conveniência para quem consome uma API, graphQL é rei mesmo; agora, se estiver otimizando pra performance, nada vai bater uma query escrita manualmente para aproveitar os índices do banco de dados.
Obrigado pelo comentário e por ter assistido ao vídeo. Sucesso!
Vídeo muito bom e direto ao ponto, difícil encontrar por aqui.
um tutorial implementando CQRS do nestjs com DDD seria incrível.
Obrigado, Danrllei 🤝 Vou fazer um sobre DDD sim, e penso até que serão alguns vídeos dedicados ao assunto, pq DDD de verdade é um negócio que exige profundidade, se não for pra fazer apenas um "DDD-light" né... mas eu sou fã de DDD, vou fazer sim :) valeu pelo incentivo!
@@PhillCode Boaaa, aí sim!
Opa Phill, conseguiria algum dia, fazer vídeo implementando DDD e o Event Sourcing ?
Boa pedida! Eu pessoalmente acho Event Sourcing difícil de acertar, mas o DDD é uma grande paixão minha. Então aceito o desafio, só não posso prometer data. Valeu pela sugestão!
Muito bom Phill 🎉
Valeu, Roberto!
Muito bom🎉🎉
Boa tarde mano, Excelente vídeo !
O que vc acha da utilização do Prisma ? Da para executar os mesmos ensinamentos dos seus vídeos ?
Fala aí George, obrigado! Eu acho super válido utilizar o Prisma, ou qualquer outro ORM que você domine e atenda às suas necessidades. Eu uso o TypeORM pelo mesmo motivo: ele atende às minhas necessidades e sei como usá-lo; não vejo motivo para me aprofundar em outro ORM que, grosso modo, faz a mesma coisa, ainda mais sabendo que tem tanta coisa ainda pra estudar 😅 Mas reforço: se ele te atende e você manja, continue com ele, vai dar certo.
Que aula!! 👏👏👏👏
✍👏👏👏👏👏 TOP D+
Parabéns pelo conteúdo excelente!
Tenho uma dúvida sobre a organização do código. Gosto da ideia de agrupar todos os recursos relacionados em um mesmo lugar, como você faz.
Mas como você lida com situações em que outras queries precisam de um recurso específico, como o employee.dto, por exemplo?
Fala Flavio, ótima pergunta! Eu costumo começar colocando o DTO junto com a própria query e, conforme vai sendo necessário, vou movendo ele gradativamente para níveis mais externos na estrutura. Acho que a estrutura de arquivos e pastas do projeto não deve ser rígida; ela deve evoluir conforme o projeto cresce e à medida que nosso entendimento sobre o problema ou negócio que estamos resolvendo também evolui.
Por exemplo, no início eu colocaria a classe de DTO no mesmo arquivo da query, dependendo do tamanho do projeto e da equipe. Depois, poderia mover para um arquivo ".dto.ts" dentro da pasta /employees/queries.
Mais adiante, pode ser interessante criar uma pasta /employees/dtos se você tiver muitos DTOs compartilhados dentro do contexto de employees. E, por fim, pode acabar em uma pasta /shared ou /common, acessada pelo contexto de employees e outros, conforme a necessidade.
Uma coisa importante é tomar cuidado com o acoplamento. É péssimo para o projeto quando você começa a adicionar propriedades ao DTO que não fazem sentido para todas as queries/contextos que o usam.
Por exemplo, digamos que o DTO começa com id e name. Você compartilha ele, e depois adiciona um dateOfBirth: Date que só faz sentido para algumas queries. Então você deixa dateOfBirth como Date | null. Mas atenção: uma coisa é deixar algo como nullable porque o dado é usado em todas as queries mas pode ser null, e outra coisa é deixar null porque só algumas queries precisam dele.
Quando chega nesse nível de acoplamento, é melhor não compartilhar. Prefira duplicar código a criar um acoplamento desnecessário, que só vai te trazer dor de cabeça no futuro.
Espero que isso ajude! Abraço!
Faz um vídeo realizado upload de imagem no firebase, não tem nenhum vídeo que mostra como faz upload para firebase usando Nestjs
Fala aí Alex! Dica anotada, meu caro! Vamos chegar no upload em breve. Nunca fiz upload pro Firebase, mas descubro e te conto! hehe
@@PhillCode consegui realizar o upload , é facil depois que nós descobri rsrsr. Depois de 3 dias batendo cabeça eu consegui
Fala Phill, tá sumido mestre? Tudo bem por aí?
Cara esse mês entrei numa startup dos USA pra trampar como fullstack e lá eles usam Nestjs no backend ... estou até retornando pra ver esses vídeos aqui da sua série... mande notícias, valeuu
Fala aí Rock, tudo bom? Obrigado demais pela mensagem, man 👊 tá tudo certo sim; passei um período com uma gripe forte, o bicho pegou, mas agora estou de volta. Tem uma questão de conciliar tempo do trabalho com o canal, afinal eu faço os vídeos no meu tempo livre, muitas vezes no fim de semana, e quando a coisa aperta no trabalho o canal sofre, hehe, mas vamos aí, a ideia é continuar.
E que legal que você está usando NestJS no trabalho. Se topar, me add no linked-in e a gente marca um papo qq dia desses pra trocar experiências. Sucesso pra você no novo desafio!
@@PhillCode show de bola mestre .... acabei de te enviar o convite no LinkedIn.... sucesso no serviço e no canal !!
da pra fazer CQRS com o Nodejs Express?
Dá sim, com certeza, mas vai dar um certo trabalho, porque o ExpressJS não dá suporte nativo pro CQRS assim como o NestJS. Você vai precisar estruturar tudo manualmente. Dá uma olhada em pacotes npm como cqrs-domain pra gerenciar comandos e eventos de domínio, e o cqrs-lite pra um framework CQRS mais leve. Como opinião pessoal, eu considero o NodeJS puro ou o ExpressJS bons para projetos pequenos e sem muita complexidade; eles são leves e não te direcionam nem te forçam a fazer as coisas de uma forma específica. Pra projetos grandes e/ou complexos, eu acho ruim porque você perde produtividade ou perde em boas práticas, porque você tem que implementar muita coisa manualmente, ou conhecer bem os pacotes que ajudam na implementação que quer fazer, e se não estiver bem afiado nos padrões que quer aplicar, o risco de meter o pé pelas mãos é grande. Foi por isso que virei fã do NestJS. Ele é opinionado e traz muita coisa pronta; isso tem seus pontos fracos, mas não se discute produtividade. Você voa!
Resolvi complementar a resposta pra dizer o seguinte: pra todo e qualquer padrão ou "boa prática", é sempre possível (e recomendado) você entender bem qual é a FILOSOFIA do padrão. Qual problema ele resolve, por que o problema aparece, e como a solução foi estruturada. A partir disso, você vai conseguir (re)implementar uma versão do padrão que seja apropriada para o seu caso de uso específico. De forma bem simples, se você implementar cada query e comando numa classe separada, implementando uma determinada interface ou classe base, e chamar essa classe no seu controller, você já vai chegar no mesmo lugar do que eu apresentei no vídeo, sem complicar e sem instalar nenhum pacote. Por isso reforço: é importante entender bem qual problema você está tentando resolver e qual parte do padrão resolve isso; daí fica fácil aplicar.
@@PhillCode que legal, eu ja estou proximo de focar no estudo do Nest. pelo visto vai ser muito util e produtivo. Eu estudei bastante o node.js por muito tempo e junto com isso ainda tive que passar muito tempo estudando javascript e uma marretada de outras coisas relacionadas a frontend com react, nextjs e etc... kkkk. Uma pergunta, com este Nest eu ja tenho classes prontas para fazer CQRS, Saga, e DDD, websocket e tudo isso ne? Vc tem cursos que ensina com contexto a essas tecnologias?
Nit understand s single word 😢
Hi! I'm sorry to hear that... but I think there's a lot of great content available in English and other languages already. So, I've chosen to focus on bringing some of that to Brazil, in Brazilian Portuguese. Perhaps in the future, I can explore providing translations or captions :)