Estrutura para novos projetos / frameworks / boilerplates

[Osvaldo Zonetti]

Bom dia :)

Gostaria de fazer uma "mini pesquisa": Como vocês iniciam novos projetos web com Node.js?

Utilizam algum framework (fora o express) que já forneça uma estrutura de diretórios e convenções, partem de uma estrutura recomendada (boilerplate) ou costumam criar uma nova estrutura específica para o projeto?

Pergunto porque infelizmente até hoje não temos um framework em Node.js assim como o Ruby tem o Rails, o Python tem o Django e o PHP tem tantos outros. Até possuímos alguns bons candidatos (Sails, Compound, Geddy, Locomotive, etc.), mas nenhum ainda é tão maduro ou popular suficiente, pelo menos ao meu ver, para ser utilizado em novos projetos "sem medo".

Gostaria de saber a posição de vocês quanto a isso :)

[Alan Hoffmeister]

Na minha opinião, pelo Node.js ter surgido em uma época diferente com
ideias diferentes, uma metodologia antiga pode demorar para se
popularizar. O que eu faço nos meus projetos é utilizar o express para
o backend servindo arquivos estáticos e rotas rest, o resto fica tudo
no frontend com o AngularJS.

Também acho que, as vezes, precisamos abrir a cabeça e estar aberto
para novos métodos, não adianta ficar remando contra a correnteza.

Se preferir continuar com a metodologia antiga pode usar qualquer um
dos candidatos que vc citou. Não espere nada popular e maduro de uma
plataforma com 4 anos de existência :)
--
Att,
Alan Hoffmeister

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "NodeJS
> Brasil" dos Grupos do Google.
> Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie
> um e-mail para nodebr+un...@googlegroups.com.
> Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

[Marcos Sampaio]

Compartilho da mesma ideia do Alan. A única diferença é que no frontend eu uso knockout.js.

--

Marcos Oliveira Sampaio

About me

[Augusto Pissarra]

Osvaldo,

Express é bastante maduro e usado em projetos como do MySpace. Eu estou usando Hapi que é usado pelo WalmartLabs em todos os seus aplicativos no Walmart. Eu usaria sem medo em qualquer tipo de projeto estas duas infra-estruturas. Eu estou usando porque estou fazendo APIs para serem usadas e não um aplicativo web per se!

Em relação a estrutura de diretórios o express sugere uma estrutura e várias outras também sugerem. Mas de fato, a melhor estrutura de diretórios é aquela criada para o seu projeto de acordo com patterns usadas e necessidades que você identifica para o seu projeto. Siga sugestões, mas defina o que você precisa.

Abs,

Augusto Bernardo (55 11) 98851-6629 www.highdesign.com.br

 

--

[Augusto Pissarra]

+1 knockout.

Augusto Bernardo (55 11) 98851-6629 www.highdesign.com.br

 

From: Marcos Sampaio <mosa...@gmail.com>
Reply-To: <nod...@googlegroups.com>

[Osvaldo Zonetti]

Pelo visto não tenho feito diferente :)

Em meu último projeto também utilizei o tal do "MEAN" (mongo, express, angular e node.js). A minha maior dúvida mesmo era quanto às convenções, estruturas e workflow que utilizam.

Eu particularmente prefiro a liberdade que temos com o express de construir nossa própria estrutura de modo a comportar projetos de vários portes, sejam eles MVC, multi módulos e até microaplicações. Mas ao mesmo tempo que gosto dessa liberdade, eu sinto um pouco de falta dos padrões, visto que em outras tecnologias como o Django por exemplo, existem padrões e boas práticas muito bem definidas de forma que facilita a colaboração, principalmente em meio a comunidade open source.

Também concordo com o fato do Node.js ser muito novo para ter algo já maduro e popular, fora o Express :)

[Pineli]

Tbm tenho mesma ideia.

Para dar uma agilizada em algumas coisas iniciais, dei uma mudada neste modulo para gerar do jeito que eu gosto e mando bala. https://github.com/madhums/node-genem

--

[MarceloMF]

Boa tarde pessoal.

Sentimos essa necessidade e começamos o graojs.
https://github.com/synackbr/graojs

https://graojs.org
http://www.slideshare.net/marcelomf/grao-js-full-stack-mvc-nodejs

Depois do projeto, começou a surgir muita coisa e estamos alinhando uma forma de sustentar o projeto e os outros projetos que surgiram por conta dele. Ainda não divulgamos, pois falta em torno de 20horas de desenvolvimento para conseguirmos lançar a primeira release e junto virá o site com documentação e também os testes unitários que devem ser implementados.

Se alguém quiser testar, segue os passos:

git clone https://github.com/synackbr/graojs

cd graojs/bin
./buildTest.sh

cd ../../demo

e você irá ver a estrutura do projeto demo e do bundle user no caso.

Antes mesmo do lançamento, a arquitetura foi reescrita 6 vezes e o gerador de código está sendo reescrito pela segunda vez. Atualmente conto com a colaboração do amigo Rafael Goulart, ele está sendo o responsável pela segunda versão do gerador. Outros amigos estão ajudando muito de outras formas que não com código. Enfim, fazer software livre é muito bom, vamos adiante.

Abraços e qualquer coisa abrimos a thread aqui e iniciamos as discussões, particularmente gostaria muito de ter o envolvimento de vocês, antes de lançarmos o projeto, quanto mais @br melhor! ;)

[]s

--

Att, Marcelo M. Fleury

Framework - http://graojs.org

Blog - http://marcelomf.blogspot.com/
Slides - http://www.slideshare.net/marcelomf/

"Adequações são necessárias a todo o tempo"

[Marcos Sampaio]

massa marcelo! só uma sugestão! poe a url https://graojs.org/ no README.md pra aparecer no github!

[MarceloMF]

Oi Marcos, faremos isso sim ;), antes do lançamento, temos que atualizar o site/doc e também fazer um videozinho... por isso o site ainda não esta sendo divulgado :)

[]s

[Marcos Sampaio]

de qquer forma, parabéns pela iniciativa!

eh sempre bom ver brasucas fazendo produtos de qualidade!

[MarceloMF]

Agradecemos.

O ideal é conseguirmos o envolvimento de vocês, portando críticas são bem vindas, sejam elas construtivas ou destrutivas, o que tiver que acontecer, vai acontecer :) hehe.

Entendo que todos tem prazos e projetos... mas FOSS é de todos, acho que vale o envolvimento, esperamos responder a altura.

[]s

[Alan Hoffmeister]

+1 pela iniciativa de um projeto brasileiro

Só falta os docs em pt-br ;)
--
Att,
Alan Hoffmeister

[MarceloMF]

Fala Alan, com certeza teremos a DOC em pt-br antes do lançamento(dezembro/2013)... é que consideramos mais simples gerar em inglês e depois traduzir, do que o contrário.

[]s

[Augusto Pissarra]

+1 é muito difícil alavancar projetos como este no Brasil e o que puder
fazer para apoiar, farei!

Parabéns pela iniciativa.

________________________________________

Augusto Bernardo
(55 11) 98851-6629
www.highdesign.com.br

________________________________________

[David Lojudice Sobrinho]

Oi Osvaldo,

Penso um pouco diferente. Uma das belezas do node e da comunidade é se herdou a filosofia Unix (http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js) e uma delas é: "Write programs that do one thing and do it well." Acho que frameworks quebram essa premissa.

Venho de alguns anos de projetos em Rails e confesso que quando estou trabalhando com node.js eu tenho uma sensação de liberdade imensa pq sei que não terei que lutar contra nenhum framework, que só preciso daquilo que é necessário para o meu projeto. Pq convenções são boas até o momento que vc precisa quebra-las. Ainda penso nas horas que eu perdi tentando colocar aquela classe que não estava descrita no livro...

Ainda fizemos poucos projetos em Node.js aqui, mas já está surgindo um padrão de diretórios que estamos usando, influenciados por coisas como DDD e DCI (http://dci-in-ruby.info/ e http://www.youtube.com/watch?v=WpkDN78P884). Ou seja, tudo que não consegui fazer direito em Rails to tentando fazer em Node.js :) 

Resumindo, diretórios de controllers, routas, views, etc (código de infraestrutura), são menos importantes que diretórios com seus objetos de negócio/domínio do problema. 

Uma outra coisa é a distinção entre código client e server logo na raiz. Inclusive com testes separados para cada um deles, como se fossem duas aplicações separadas. Isso foi tranquilo pq até agora só fizemos aplicação single-page (Backbone / Angular) e Node.js e talvez isso não seja tão tranquilo com páginas tradicionais.

Sim, é meio diferente do que vemos nos frameworks que vc citou, mas essa é a beleza de se ter liberdade de poder fazer isso.

2013/11/29 Osvaldo Zonetti <zon...@gmail.com>

--

Você está recebendo esta mensagem porque se inscreveu no grupo "NodeJS Brasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para nodebr+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--
__________________

   David L. S.
dals...@gmail.com
__________________

[MarceloMF]

Fala David, bacana seu ponto de vista.

Ainda assim as convenções são necessários para obtermos interoperabilidade, massificação de melhores práticas e finalmente nos colocarmos em uma posição de questionar essas "melhores práticas". Talvez o exemplo mais baixo nível que eu possa te dar, é no prologue da função, onde em x64, o processador utiliza alguns registradores para os 6 primeiros argumentos de classe INT[0][1] e em 32bits não era assim, simplesmente empurrávamos para a stack. Então veja, se cada fabricantes implementar tudo ao seu gosto, como poderiam então os compiladores reaproveitarem código para diferentes fabricantes ? Claro que sempre cada fabricante terá conjuntos de instruções e funcionalidades próprias, entretanto este não é um argumento para a não convenção das coisas.

Assim que tiver um tempo, irei estudar o material que você postou e posto minha opinião.

Enquanto isso, te convido a questionar como o Rails é implementado e como todas as outras frameworks MVC são implementadas... vamos fazer algo melhor, a ideia é essa, conseguindo ou não, é diversão garantida :).

[]s

[0] http://stackoverflow.com/questions/4265970/c-to-assembly-call-convention-32bit-vs-64bit
[1] http://www.x86-64.org/documentation/abi.pdf

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Node.js Brasil" dos Grupos do Google.

Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para nodebr+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

[David Lojudice Sobrinho]

Oi Marcelo,

No seu exemplo são dois "componentes" (aplicação e processador) com interfaces bem definidas de como eles devem se comunicar, cada um com seu encapsulamento (a aplicação não conhece de transistores e afins assim como o processador não faz idéia pra que serve a aplicação).

No caso de uma aplicação que vc está desenvolvendo, seja node.js ou whatever, vc deve ter liberdade total já que o que tem ali dentro esta sob seu controle, com liberdade para furar qualquer abstração e interface que vc bem entender. Caso haja interação com outras aplicações externas, sua aplicação deve expor interfaces bem definidas tb, como o processado.

E ai entram os frameworks com um tradeoff: liberdade vs. uma promessa de ganho de produtividade. Alguns frameworks impõe convenções e isso tem alguns ganhos, mas o problema é quando o framework não sabe lidar com os casos de excessão (que acontece tanto que nem considero excessão) e ai o ganho vai pro ralo. Alguns frameworks são mais permissivos que outros, claro, mas ai o "ganho" tb não é tão grande.

No geral, minha percepção é que os frameworks com "forte opinião" tem uma tração maior pois dá a impressão que temos facilidade em modelar nosso problema de maneira fácil, basta colocar um pouco de código no controller, outro na view e no model e pronto: estamos usando OO! (sim Rails, estou olhando pra vc!) E minha experiência diz que o MVC não é suficiente para dar conta de modelar uma aplicação, principalmente aquelas que nós desenvolvemos aqui, voltadas para o negócio. Sem contar que a maioria dos frameworks atrapalham MUITO os testes, tendo sempre que fazer gambiarras para funcionar com testes automatizados. 

Tenho certeza que existem excessões, mas resumindo, hoje estou contente de poder pegar apenas os pequenos módulos que resolvem problemas bem definidos e montar o meu próprio stack, com os padrões e convenções que fazem sentido para o projeto.

2013/12/5 MarceloMF <marc...@gmail.com>

[Osvaldo Zonetti]

Ótimo ponto David, concordo plenamente com os benefícios dessa liberdade que temos no node.

E cada vez mais estou me tornando partidário dessa abordagem de construir uma stack mais voltada para o domínio do problema. De fato uma abordagem que vem de encontro com a proposta do Unix.

Afinal, "Those who do not understand Unix are condemned to reinvent it, poorly".

On Friday, November 29, 2013 9:37:19 AM UTC-2, Osvaldo Zonetti wrote:

[MarceloMF]

Oi David,

Oi Marcelo,

No seu exemplo são dois "componentes" (aplicação e processador) com interfaces bem definidas de como eles devem se comunicar, cada um com seu encapsulamento (a aplicação não conhece de transistores e afins assim como o processador não faz idéia pra que serve a aplicação).

Não manjo de transistores, estava me referindo a processadores diversos <> assembly <> compiladores

Normalmente boas convenções são abstratas e extensíveis, não engessam.

 

No caso de uma aplicação que vc está desenvolvendo, seja node.js ou whatever, vc deve ter liberdade total já que o que tem ali dentro esta sob seu controle, com liberdade para furar qualquer abstração e interface que vc bem entender. Caso haja interação com outras aplicações externas, sua aplicação deve expor interfaces bem definidas tb, como o processado.

Acredito que aqui fugiu do tema frameworks para o tema middleware/rest/soap-wsdl/soa/etc. Toda via, nada impede da sua framework utilizar restful/json para todas as requests, que inclusive o scaffolding funcione assim.

 

E ai entram os frameworks com um tradeoff: liberdade vs. uma promessa de ganho de produtividade. Alguns frameworks impõe convenções e isso tem alguns ganhos, mas o problema é quando o framework não sabe lidar com os casos de excessão (que acontece tanto que nem considero excessão) e ai o ganho vai pro ralo. Alguns frameworks são mais permissivos que outros, claro, mas ai o "ganho" tb não é tão grande.

Acredite, eu sei do que você esta falando e passei MUITO por isso quando usava php/symfony, uma framework que acompanhei da 1.0, pela 1.2, 1.4 até 2.0. Eu realmente entendo suas preocupações e partilho delas.

 

No geral, minha percepção é que os frameworks com "forte opinião" tem uma tração maior pois dá a impressão que temos facilidade em modelar nosso problema de maneira fácil, basta colocar um pouco de código no controller, outro na view e no model e pronto: estamos usando OO! (sim Rails, estou olhando pra vc!) E minha experiência diz que o MVC não é suficiente para dar conta de modelar uma aplicação, principalmente aquelas que nós desenvolvemos aqui, voltadas para o negócio. Sem contar que a maioria dos frameworks atrapalham MUITO os testes, tendo sempre que fazer gambiarras para funcionar com testes automatizados. 

Não codei em RoR, mas vários dos seus conceitos utilizei no symfony. Com relação aos testes, talvez tenha sido uma experiência pontual.

 

Tenho certeza que existem excessões, mas resumindo, hoje estou contente de poder pegar apenas os pequenos módulos que resolvem problemas bem definidos e montar o meu próprio stack, com os padrões e convenções que fazem sentido para o projeto.

Particularmente considero um grande risco dar toda essa liberdade para desenvolvedores iniciantes, se você é um cara experiente e manja por exemplo de cabo a rabo do projeto OWASP, modelos de acesso e padrões de projeto, enfim, vá adiante... agora se você não tem esse perfil(e mesmo tendo), continuo acreditando que o uso de frameworks que por padrão te oferecem várias funcionalidades de segurança e te entregam código de qualidade, não engessando qualquer implementação/customização futura, continuo acreditando que sim, isso é bom.

Mas respeito tua opinião e afinal, sou suspeito para falar sobre o assunto hehe ;).

[]s