Nest Resolve o Maior Problema do DEV?

Рет қаралды 6,639

Күн бұрын

Пікірлер: 34

@deyvisonborges 6 ай бұрын

Geralmente eu separo em Core e App, onde toda logica agnostica do negocio fica na pasta core com Typescript e, o Nest (na camada de App) somente consome e implementa, tendo assim, uma arquitetura mais purista.

@moimsk8 6 ай бұрын

O NestJS força o programador a seguir um design pattern de início, mas ele pode ser extensível, como se fosse o Rails do Ruby. Eu particularmente prefiro utilizar o Express ou o Fastify direto para criar as rotas HTTP na mão, implemento os padrões UseCase para as regras de negócio e Repository para a persistência dos dados, sem esquecer de injeção de dependências onde eu utilizo o Inversify (mas podem utilizar o Tsyringe que faz a mesma coisa). A grande vantagem do Nest é não se preocupar com tudo isso que falei, mas é preferência.

@jhonatanfrade3763 6 ай бұрын

Melhor insight: "Você é o responsável pela arquitetura"

@DimensaoGeekk 6 ай бұрын

Eu gosto do Nest porque ele te dá a opção de seguir o padrão dele mas ainda te deixa controlar quase tudo. E o que ele não me deixa controlar é justamente o que eu evito. Fiz um boilerplate que nasceu sem Nest e na hora de migrar para Nest foi super de boa e resolveu problemas de transpilação e performance, mas tento sempre manter a aplicação de forma que conseguiria facilmente reverter e retirar o Nest. Uma das coisas que evito é usar bibliotecas de logging, cloud SDK e ORM de dentro do Nest. Também evito deixar toda a complexidade das validações de input nos decorators do class-validator, apenas deixo validações básicas, as mais complexas ficam em módulos de schema que usam Joi (pelo controle maior das validações) ou Zod (pela tipagem dos schemas). Se deixasse no Nest ia perder tudo caso parasse de usar ele. Gosto de organizar por contextos, isso me facilitou na migração pro Nest e facilita pra desfazer a migração. Tudo que é básico para a aplicação rodar (banco de dados, cloud, logging, configs) fica no módulo Core. A camada de Domain fica separada e independe dos models de banco de dados, contém as entidades e enums da aplicação. As regras de negócio ficam nos usecases e services do módulo App. Os módulos globais usados nos controllers do App ficam em API. Os utils, helpers e constantes usados em qualquer outro módulo ficam no módulo Common. Eventos assíncronos como filas e websockets ficam na camada Events.

@Mk-lc6pg 6 ай бұрын

Pela minha experiência a maioria das aplicações que trabalhei em NodeJs foram feitas em express com algo parecido com no máximo um MVC, muito por falta de conhecimento dos próprios devs mesmo. Creio que por JS ser muito acessível, então tem 10000000 de tutoriais de criar uma API básica que se quer pensa em arquitetura. Então creio que nesse quesito o Nest seja interessante, principalmente se você ainda não tem conhecimento de arquitetura, patterns etc, você começa a entender como e porque alguns patterns são usados. Mas claramente, se você já tem conhecimento de arquitetura e tem um plano bem definido para a aplicação, talvez ele vai mais atrapalhar do que ajudar.

@paulocavalheirodeveloper1213 6 ай бұрын

Sai do loopback e fui estudar o Nest, além de ter uma baixa curva de aprendizado, ele meio que te força se manter nos trilhos corretos em questão de padrão de projetos.

@Bambatera 6 ай бұрын

Experiência prática: a alguns anos, foi desenvolvido um framework para uso nos projetos de software da UnB, a ideia foi muito boa, a abstração era pra agilizar o desenvolvimento de aplicações web usando JSF, porém, teve um alto custo de manutenção, os componentes ficaram muito acoplados o que dificultou bastante as correções de bugs e evoluções nos projetos. Ja dizia um professor meu, não reinvente a roda! Nao sou contra novas abstrações pra facilitar ou melhorar a produtividade, não concordo em acoplamento demais, isso apneas atrapalha!

@antonioalexandrealonsodesi4185 6 ай бұрын

Framework: Um framework é uma estrutura fundamental para a criação de uma aplicação. Alguns frameworks são mais restritivos quanto ao que é permitido fazer, e cada um possui um modus operandi próprio. Se você não se adapta à estrutura de um determinado framework, sente-se limitado, ou se ele não oferece recursos que justifiquem suas limitações, e exige muito código boilerplate que você considera desnecessário, é aconselhável buscar outra opção. Tentar adaptar um framework ao seu estilo de programação, em vez de ajustar-se ao modo de operação proposto pelo framework, pode ser uma tarefa árdua e, por vezes, frustrante. O mais indicado é usar o framework conforme ele foi concebido. Se essa abordagem não atender às necessidades do seu projeto, o mais sensato é buscar uma solução alternativa. Quando eu programava em PHP, tinha dificuldade em me adaptar à maioria dos frameworks, pois eram muito rígidos e, para realizar tarefas simples, precisava criar muitas classes e escrever muito código apenas para que o framework se orientasse em suas próprias estruturas. Por isso, desenvolvi meu próprio framework MVC, seguindo o que considerava mais adequado para tornar meu trabalho menos penoso. Quase dez anos depois, já trabalhando com Java, descobri o Spring Boot e fiquei encantado, pois ele seguia a mesma filosofia do framework PHP que eu havia criado para facilitar meu trabalho. Atualmente, continuo utilizando o Spring Boot na programação Java e estou expandindo meus horizontes, explorando frameworks JavaScript que rodam com Node e TypeScript. Resumo: Concordo que um framework deve ser flexível e permitir a adoção de diferentes arquiteturas, com poucas imposições. No entanto, se estamos trabalhando em um projeto que já utiliza um determinado framework, devemos procurar abraçá-lo e não lutar contra ele.

@BrunolimaMe 6 ай бұрын

Falando em PHP, já vi muita vaga, até pagando bem, mas não para trabalhar com PHP, mas sim com Laravel. Isso bate na tecla que você falou, do framework ditar como você deve organizar e o que você deve usar. Não desmerecendo o Laravel em nada, mas isso é uma coisa que nunca gostei nele, ou você faz como ele determina ou não funciona

@israelsousa 6 ай бұрын

Exatamente

@CaetanoF.S 6 ай бұрын

Boa análise! Você é um grande especialista na área de dev e tem uma boa didática.

@leonardoncintra 6 ай бұрын

Gostei da parte que ele usa a mesma coisa no Nextjs e no NestsJs Estou repetindo as interfaces, tudo com o mesmo nome e estrutura. As vezes separar realmente economiza tempo, e independencia. obrigado xará!

@Gygaweb 6 ай бұрын

Grande mestre! Me deu aula no curso de java la na antônio sales!

@allanfarias1988 6 ай бұрын

Show..recado dado de quem entende do assunto...

@noriller 6 ай бұрын

Eu diria que é menos arquitetura e mais "organização de pastas". Fora que, acho que o que o Nest faz que outros frameworks pecam é que ele, por si só, não "faz muita coisa". Isso porque você pode simplesmente trazer as libs que você quer sem depender de algo do Nest. Tem uns framework que "tem tudo" o que precisa, tudo feito pelo mesmo framework. Dai a dependencia fica maior, porque as vezes é tão acoplado que não tem como rodar o que precisa fora do contexto do framework (exemplo: adonis). Uma possível "separação" com o Nest seria traumatizante, mas se está usando o prisma, koa, vitest... fica um pouco mais simples de separar o que é lib, do que é nest, do que é "seu código".

@CristianoUnix 6 ай бұрын

É aquela velha história, quando menor acoplamento melhor, nesse caso seria o acoplamento do core re regras da aplicação com o framework.

@WillianMattos 6 ай бұрын

Penso que só o fato de usar um decorator em uma entity já polui o código com a framework. Já passei pela experiência de criar tudo na mão, incluindo mappers, etc.. mas profissionalmente nunca vi um domínio verdadeiramente puro, seja em Java, Kotlin ou C# .Net. O NestJs é basicamente a mesma coisa, só facilita um pouco mais com o conceito de módulos na hora de fazer inversão de dependência. Na prática, se o cara quiser criar 70 milhões de pastas divididas entre camadas pra implementar um cqrs, ele vai conseguir no Nest também 😅

@thiagosousa4141 6 ай бұрын

esse esquema de ter uma arquitetura base que você pode modificar de acordo com o seu cenário/demanda vejo sendo muito bem feito no .NET Core, o framework em si "obriga" seguir suas regras somente na parte de interface com o mundo externo (seja api ou web), que a meu ver é uma mão na roda, visto que principalmente as apis já possuem uma estrutura definida de funcionamento e protocolos (http + json em sua maioria) e isso te deixa livre para cuidar do mais importante que é a estrutura e os códigos. fora a questão da injeção de depedências que pra mim é a mais perfeita de todas que já conheci, sabendo o que é sigletown, scoped etc. o resto o framework faz por você com excelência, voltando novamente ao ponto de que você tem que se preocupar com o código, arquitetura e regras de negócios. me parece um cenário todo bem estruturado/fechado e aberto a customizações ao mesmo tempo, banco de dados é a prova disso, hoje o Dapper (biblioteca alternativa) é muito mais utilizado que o EF (biblioteca do framework).

@brunocotto 6 ай бұрын

Super palpável utilizar DDD e Clean Arch com o NestJS. Inclusive na empresa que trabalho atualmente estamos utilizando ele, mas, mantendo o domínio/regras de negócios isoladas.