Qual será a finalidade do Braz.io?

[luanmuniz]

Será realmente um gerenciador de conteúdo? Faremos dele algo para construção de API's onde o software consumirá o banco e entregará um estatico? Qual será a real finalidade dele, só depois que decidirmos isso podemos decidir estrutura de pastas, estrutura primaria de banco e de dados.

[luanmuniz]

O Node.js é perfeito para entregar arquivos estaticos, então eu voto em fazer algo voltado para contrução de API. Uma aplicação de consuma o banco e entregue um json ou xml.

O @suissa sugeriu de fazermos isso dentro de um modulo do CMS, o que também acho valido

[fdaciuk]

Acho que seria legal ser como o WordPress. Inclusive tem algumas coisas legais dele que podemos "trazer" pra cá.. ia ficar da hora e bem intuitivo! O que acham?

[gnuwilliam]

Acho legal o modelo do WordPress em relação a customização. Criar temas, plugins, utilizar hooks do core da plataforma, moldar do jeito que você precisa.

Isso brilharia os olhos de muita gente, e tenho certeza que iria extender as possibilidades do projeto. :-)

[fdaciuk]

Essas são as coisas legais dele! E podemos fazer tudo como uma API Rest.. ficaria muito doido xD

[caarlos0]

Embora eu goste do estilo Jekyll de ser, acredito que "pra o povão usar", melhor seria seguir a linha wordpress da vida..

A idéia da API comentada acima += 1 :beer:

Also, tem os outros CMS's, drupal por exemplo... vamos seguir essa idéia "mais genérica" ou literalmente fazer um wordpress usando node.js (no sentido de wordpress ser inicialmente voltado a blogs)?

[mateusavila]

Eu penso em uma solução genérica e que possa ser ampliada com componentes que seguem rigorosamente a filosofia do projeto (e não a Mãe Joana do Wordpress, que qualquer plugin pode ser feito, sem o mínimo de preparo com a segurança e a qualidade).

[nicholasess]

Como o Nodejs é novo no mercado, não será fácil pra desenvolver um plugin zuado, a maioria das soluções são de ótima qualidade. Acredito que seguindo o mesmo estilo do Wordpress poderemos abranger um mercado, competindo de frente com o wordpress

[luanmuniz]

Posso estar equivocado, mas poucos provedores de hospedagens usados pelo "povão" tem um plano com suporte a nodejs, com acesso ssh para usuário acessar o console e fazer as instalações necessárias (Estou falando de planos de hospedagem comum, não dedicados ou semi-dedicados). Tendo isso e o fato que o nodejs está sempre em atualização e a aplicação necessitaria de um suporte constante para atualizações e etc, acho que fazer algo "para o pavão" não seja a melhor escolha. Este artigo na parte "Convincing a client" tem uma defesa bem interessante de porque para o povão pode não ser uma boa escolha.

Acho que poderíamos tentar entregar algo mais estático mesmo tipo sites institucionais e páginas estáticas, algo sem muitas condições de acesso e sem muita necessidade de processamento. Acho que algo como o WordPress ou o Drupal não é a proposta do nodejs (Pode até ser feito, mas acho que podemos fazer algo mais interessante) Eu concordo totalmente com o artigo que citei acima e acho que deveríamos ter coisas parecidas em mente enquanto decidimos a finalidade do braz.io.

[mateusavila]

Luan, penso que justamente o problema de hoje do node é que é uma solução muito "elitista", apenas programadores com um certo conhecimento elevado em javascript conseguiriam fazer algumas mágicas. O fato de criar um concorrente ao wordpress pode fazer popularizar a tecnologia com outros desenvolvedores, e fazer com que empresas que ganham seus centavos com hospedagem em PHP e MySQL se preocupem em pegar esses clientes que estão migrando para o Node.

Em relação aos componentes que são produzidos, é importante que haja uma garantia de qualidade, pois javascript tem alguns probleminhas como a poluição do escopo global e também há possibilidades de ataques XSS. É importante o CMS nascer com essa preocupação. Afinal, uma hora vai ter que liberar a API para criação de componentes extras ao projeto. Por sorte ainda, quem desenvolve em node tem um grande conhecimento em JS, mas há o problema de se popularizar demais, e não ter nenhum controle.

Vamos botar a discussão em um nível legal, para que os consensos surjam e possamos fazer um CMS de qualidade :D

[oswaldoacauan]

@luanmuniz +1

Tambem vejo poucos provedores do "povão" com suporte a Nodejs.

[fdaciuk]

Pois é.. essa questão de servidor é algo a se colocar na balança. Mas se for olhar para a questão de que o CMS terá uma API Rest, ele poderá ser consumido por qualquer tipo de linguagem.

Essas coisas que são legais pegar do WP: a forma como ele entrega as info para o front.

O CMS vai poder ter uma instalação completamente separada do tema do site.

Claro que no nosso caso, vamos usar Angular pra consumir os dados, mas nada impede do cara ter o CMS instalado em um outro servidor e consumir com PHP, Ruby, Python e até .NOT (ops, .NET =P) se quiser xD

[chrisenytc]

+1 para uma API Restful \O/ Acho valido criar um modulo para possibilitar isso e até liberaria consumo de memória e processo quando não é preciso usar. Não seria necessário colocar uma API como default como modulo estaria muito bom..

[nicholasess]

+1 API Restful, interessante é que poderiamos abranger várias linguagens back ends, e várias pessoas que ainda não estão situadas com nodejs, possam programar na sua linguagem preferida.

[suissa]

Galera a ideia eh que cada módulo seja um webservice que implemente uma interface de comunicação restful. Também acho interessante implementarmos um interface de sockets, deixando o sistema maia realtime e baseado em eventos.

Nesse formato os módulos podem ser implementados em qualquer linguagem.

[suissa]

Alias a ideia de basear o sistema em eventos com sockets eh como turbinar os hooks do wp.

[luanmuniz]

Tive uma ideia aqui. Meio que baseado no que o Suissa falou. O que acham de fazermos um sistema assim:

Seria basicamente um Framework para CMS. Teria uma pasta de módulos e um arquivo de configuração. No arquivo na verdade você só diria quais módulos estão ativos e o Braz.io na verdade seria só um sistema que reúne todos os módulos que o usuário quer num backend para CRUD, configuração etc desse modulo.

Os módulos padrões seriam basicamente os de usuário, de upload e de configuração do sistema. Com o CMS puro não teria nada para realmente colocar conteúdo, para fazer um blog você baixaria o modulo de blog que algum usuário da comunidade fez e instalaria, se você quer usar como API, baixe o modulo de API e use e assim por diante.

O que acham?

[suissa]

Na verdade a ideia é bem isso mesmo uma arquitetura base onde os módulos possam ser usados, essa arquitetura será a cola que conecta os módulos e gerencia as ações dentro do sistema. Utilizando de padronização entre a comunicação de cada um e também um "auto" conhecimento dos módulos a serem ligaros através de objetos de help na API, conseguiremos escrever módulos em outras linguagens também.

[chrisenytc]

Interessante...

[robotlolita]

O problema de módulos em linguagens diferentes é o overhead de comunicação interna entre eles. No mínimo você tem os problemas de serialização/deserialização. Manter todos os módulos em JS ou C++ permite que os objetos interajam entre si com o mesmo modelo de memória. Outro benefício é manter a instalação e configuração de módulos simples, porque daí a gente pode simplemente utilizar o NPM.

[fabiorogeriosj]

Gostei da solução do suissa complementada pelo luan!

[danieltartarottisobrosa]

Acho legal a ideia de o framework ser o mais genérico possível e permitindo, como o @killdream mencionou, fazer sua instalação através do NPM. Isso tornaria muito rápido e fácil a instalação de novos módulos. Porém acredito que deveria ser tudo focado em NodeJS, pois iria simplificar muito o desenvolvimento do projeto e dos módulos futuramente.

[danieltartarottisobrosa]

Já o fato de não existir servidores "populares" para hospedagem de projetos NodeJS é algo bem relevante que deve ser analisado com bastante cautela... pois se não houver adoção por parte dos sites de hospedagem complica o futuro do projeto.

[chrisenytc]

Conheço várias plataformas para hospedar node.js. Hoje esses serviços de alta performance não existe mais para "populares" e sim para alta demanda. O PaaS agora é extremamente usado e a maioria deles dá suporte a Node.js, principalmente Openshift, Heroku, AppFog e muitos outros.

[danieltartarottisobrosa]

Dei uma olhada nessas ferramentas que o @chrisenytc falou acima, e realmente não há mais problemas quanto à hospedagem NodeJS. Inclusive há possibilidade de hospedagem gratuita. Legal mesmo.

[chrisenytc]

@danieltartarottisobrosa É muito legal mesmo e em praticamente todos os meus projetos uso eles e a Amazon também dá suporte a Node.js.

[oswaldoacauan]

@chrisenytc @danieltartarottisobrosa

Na palestra do Zeke na BrazilJS ele disse que existem milhões de apps Node no Heroku, mas muito pouca coisa disso é em produção, as empresas ainda tem um pouco de receio por se tratar de algo relativamente novo.

[chrisenytc]

É verdade @oswaldoacauan mais conheço alguns em produção bem legais. O C9.io é feito em Node.js e hospedado no Openshift e o Koding.com também é feito em Node.js e Geekli.st também feito em node.js. Mais realmente ainda falta um pouco de atuação das empresas.

[gustavohenke]

@oswaldoacauan eu lembro disso!

Convenhamos:

• O nosso CMS não ficará pronto do dia pra noite. Há tempo pra uma popularização (ainda maior!) do Node como plataforma de desenvolvimento.
• O desenvolvedor que opta pelo Node já sabe de antemão que ele não é o PHP, que você chuta uma moita e surgem 30 hospedagens. Por isso acho justo fornecer bastante ajuda ao usuário final na escolha da hospedagem.

Acredito que possamos até mesmo oferecer um setup automatizado do CMS e mantido por nós mesmos, como é o caso do wordpress.com. Dá até pra oferecer planos de hospedagem mai avançado$ (número de acessos ilimitados, possibilidade de customização maior, etc).

[suissa]

Falou tudo @oswaldoacauan e sim nosso sistema será focado incialmente no Node.js mas não podemos pensar pequeno, precisamos deixar o caminho da evolução o mais suave possível. Acredito que todos pegaram bem o conceito de como será, o que nos falta é discutir a arquitetura de como fazer.

[oswaldoacauan]

@gustavohenke @suissa Exatamente, antes de pensar em plano de hospedagem, piriri, pororo, precisamos pensar na arquitetura e fazer a mágica acontecer. Depois que essa primeira (e mais dificil) parte estiver pronta, pode-se pensar em uma parceria com uma Heroku da vida.

[chrisenytc]

O Heroku gosta muito de apoiar projetos open-source. A maioria dos addons quem tem lá começaram com betas muito limitados mais receberam apoio. O Core deve ser a maior preocupação por hora. :+1: