Lista de frameworks e libs que serão utilizadas

[diegoarcega]

Ja foi decidido quais serão as libs e frameworks que esse projeto vai usar? Poderiamos comecar a discutir isso agora.

Para backend eu recomensaria nestjs. Algo que não vi decidio também é a lib que vai fazer as async requests no redux, recomendaria o reduxsaga.

[marcos-nunes-dev]

Olá Diego! obrigado primeiramente pelo interesse! eu coloquei uma lista aqui -> https://github.com/MarcosRenato266/Grow-Roadmaps/blob/master/docs/Contribution.md onde falo sobre as libs mas a verdade é que o backend ainda não tem nada. Se você for o primeiro a contribuir com essa parte por mim não vejo problema em usar nest.js ao invés de express como eu falo na doc, só peço que se for usar por favor mande no pr a atualização no .md a cima com o "kit" que você iniciou. Em relação as requests async eu gostaria bastante de utilizar graphql tive ótima experiencia com a utilização, mas na verdade foi como eu falei o grande ponto pra mim é termos um mvp rodando e depois escalarmos a plataforma. Se for necessário podemos fazer de outro modo. Em relação ao saga por mim não tem problema usarmos ele ou thunk ou qq outra coisa do genero. Você pode se sentir bem a vontade para escolher as suas libs e frames, só peço que no pr especifique a necessidade e vantagens para não sairmos acrescentando milhões de coisas :)

[diegoarcega]

Ah, obrigado por linkar a area de contribution, ateh tinha lido mas passou batido.

Para o aprendizado e pratica talvez fosse melhor fazer sem framework(nestjs). Para produtividade talvez usar o nestjs fosse interessante. Como o growroadmap eh focado em aprendizado, talvez fosse melhor fazer as coisas mais explicitas para todos poderem ver como funciona debaixo dos panos.

Outras duvidas que fiquei:,

1. o codigo vai ser em ingles e o conteudo do sistema em PT?
2. o que acha de usar Typescript tambem?
3. usar algum boilerplate?

[filhodanuvem]

Gosto da ideia do @MarcosRenato266 de focar num mvp e tentar lançar essa versão de forma rápida, sendo assim sou a favor de usar frameworks. Eu vejo essa iniciativa ajudando pessoas em dois pontos:

• usuários/consumidores da plataforma.
• pessoas que querem contribuir.

Ainda na minha visão o primeiro ponto é o mais importante então acho difícil e pouco vantajoso escrever código em português/fazer coisas sem frameworks e libs/etc ... O que acham dessa opinião?

[marcos-nunes-dev]

Cloudson eu concordo acho assim, de certo ponto não tenho nada contra libs só temos que tomar cuidado com o excesso. Uma refatoração e melhorias depois do mvp é bem comum e até já esperado, mas temos que tentar causar pontos assim ao mínimo. Ou seja eu to usando antd para lib de ui por exemplo... evitar colocar outras e assim por diante. Em relação a colocar o código em portugues eu acho uma má prática, até porque hoje estamos em ambito nacional, mas com fé esse projeto vai ser grande e talvez tenhamos pessoas de outros paises contribuindo, é muito importante que seja em inglês. Por isso até coloquei já com "need help" o i18next e talss. Mas só resumindo o ponto de usar libs não vejo problema algum principalmente por ser um mvp dps a gente vai limpando.

[filhodanuvem]

@diegoarcega você quer puxar o setup do backend? Uma pull request colocando o nestjs com um hello world seria o bastante. Prefiro alguém que já tenha experiência nesse ambiente e na ferramenta pra começar, nunca trabalhei com nestjs.
Não falamos da base de dados, alguém contra o mongodb ?

[rafaelalmeidatk]

Os dados do app são relacionais então o ideal é usar um RDBMS, na minha opinião o melhor é o PostgreSQL.

Não tenho usado nenhum framework pra backend ultimamente, então estou interessado em saber os benefícios de usar o NestJS tirando o argumento de que "é mais rápido de desenvolver", o que não é bem verdade quando você possui já uma base sem frameworks. Manter o código simples e sem abstrações facilita o entendimento de quem quer contribuir pro projeto. Acredito que usar GraphQL ao invés de REST é melhor tanto para o back-end quanto para o front-end, então não haverão muitas rotas na API de qualquer forma.

[xavierleonardo]

Opinando aqui, acho que há uma questão de paradigma a ser levado em conta nesta escolha também. Existe certos caminhos que são naturais em um mundo e completamente sem sentido em outro. Por exemplo, NestJS faz todo o sentido em um projeto com front em Angular e pouco sentido em um projeto com front em React. Embora front e back sejam aplicações separadas, são noivas e precisam se casar bem se quiserem um casamento duradouro. Portanto acho que vale a pena considerar usar os mesmos conceitos e paradigmas em todos os lados, pois no mundo do código os opostos não se atraem.

[diegoarcega]

Podemos também listar alguns boilerplates interessantes que ja foram desenvolvidos pela comunidade e o pessoal aqui votar no que acha mais interessante para o projeto. Começar do zero zero não acho que precisamos.

Eu também nunca trabalhei com nestjs antes, o problema principal que ele ataca é a arquitetura/estrutura/organizacao do projeto. Achei ele bem straight forward, projetos node tendem a ter uma organizacao muito diferente variando de projeto a projeto e com o nest me parece seguir um padrão mais facil de trabalhar.

Quanto ao DB eu não saberia argumentar tanto pra mongo quanto pra postgre, a primeira impressão me parece que nao faz diferenca significante num projeto deste porte.

Sobre projetos com nestjs no backend fazer mais sentido com angular no front eu entendo o teu ponto porque a arquitetura de um foi inspirada pelo outro porém não acho que isso seja um problema , é possivel trabalhar tranquilamente com os dois modelos.

[marcos-nunes-dev]

Pessoal comecei ja uma base, o PR está em https://github.com/MarcosRenato266/Grow-Roadmaps/pull/15

se quiserem deem suas considerações por favor.

[marcos-nunes-dev]

Projeto Já iniciado, novas libs ou qualquer coisa do genero iniciar uma nova issue