Jails – MVC + AMD, repensando a arquitetura Javascript.

E aí galera, hoje estou retornando ao blog depois de muito tempo sem postar. E hoje é por um motivo pessoal muito bom =D.

Estou lançando o beta do meu framework para aplicações Js, o Jails! Faz um tempo que postei aqui sobre a minha iniciativa em desenvolver uma solução que ajudasse no desenvolvimento em javascript.

O princípio…

Eu comecei no blog mesmo a divulgar uma tentativa bem discreta de desenvolver um framework mvc que eu chamava de Jails. O nome era só uma brincadeira com o nome Rails, não tem nenhuma outra semelhança, e embora o nome Jails em inglês seja “Prisão” ou “Cadeia” eu gostei muito da sonoridade e da forma engraçada como surgiu quando disse : Rails para Javascript? Jails!… Foi mais engraçado na hora hahahhaa.

Eu havia parado de postar porque a minha criatividade já estava ficando limitada, eu percebia que os posts mais acessados eram os que eu não gostava muito de falar, coisas bem simples mesmo e que não tinham muito desafio. Como um blog não é um fórum, não queria usar dessas informações do google para criar posts e ganhar mais visitas.. Então comecei a pensar nos projetos paralelos, coisas que poderiam ajudar outras pessoas, foi assim que comecei a trabalhar neste humilde framework

A motivação

Eu nesse tempo meio distante do blog trabalhei em um projeto enorme, num e-commerce muito conhecido e muito grande… E comecei a conhecer o mundo dos sites que precisam mais do que firula, precisam ser funcionais, precisam fazer sentido… Quando se trabalha em agência, muitas vezes cai em projeto que você mesmo não acredita, porque realmente é um projeto de bosta. Mas agora estava trabalhando em algo sério.

Conheci a Requirejs, já pensava em módulos antes, não era um conceito totalmente novo, mas a forma como ele resolvia os problemas era genial, então aquela fissura por MVC estava diminuindo. O negócio era desenvolver Módulos.

O problema dos AMD’s..

Após trabalhar 2 anos usando AMD, descobri que eu não conseguia reaproveitar muito bem os módulos, aliás, o que era um módulo? A RequireJS não era e não é um framework, ela é uma biblioteca. Não é suficiente saber o que é um AMD, você precisa desenvolver sua arquitetura com estes módulos se relacionando.

Quando você trabalha em equipe, você precisa lidar com códigos que são completamente diferente dos seus, você precisa fazer componentes reutilizáveis nos módulos de outro desenvolvedor. No meu caso, nem os meus módulos eram reaproveitáveis, nem os dos outros devs.

A gente não conseguia também desenvolver numa mesma tela, módulos diferentes que no final se conversassem. Afinal de contas, o que era módulo? Até onde um módulo deve chegar ou até quanto ele deve saber da aplicação?

O AMD resolveu muitos problemas, até para refatorar é uma maravilha. Mas ele não resolveu o principal problema. Como devem ser desenvolvidos os módulos e como devem relacionar entre si. Quando percebemos isso, já era tarde, já tinhamos muitos módulos que não se conversavam, resolviam mais problemas do que deveriam, não eram reutilizáveis e toda hora tínhamos que resolver os mesmos problemas… As novas soluções vieram, mas cada um as desenvolvia no seu jeito, e agora temos um novo problema, uma aplicação sem padrão.

Soluções do mercado

Após essa reflexão, cheguei a conclusão de que tínhamos algumas ferramentas boas que resolviam determinados problemas como a RequirejsMustacheHandlebars, etc… Mas não tínhamos um FRAMEWORK. Um framework é importante para qualquer projeto, ele deve tentar reunir um conjunto de ferramentas, criar padrões para que seja o mais reutilizável possível, e te faça resolver cada vez menos os mesmos problemas.

Os frameworks que mais me chamavam a atenção eram: Angular, Ember, Backbone, React. Todos eles são geniais, excelentes e aprendi muito com eles. Mas comecei a identificar problemas, tentei repensar no projeto usando cada um deles. O grande problema é que eles não resolveriam os nossos problemas da melhor forma possível, eles até fariam isso, se usássemos todos eles juntos. Eu percebi que precisava de um framework que fosse a intersecção das melhores coisas que eles tinham na minha concepção do que era ideal pro projeto.

E o Jails….

Então retomei um projeto antigo, um projeto bem simples e discreto que tentava abstrair uma aplicação em 3 camadas. Model, View e Controller. Com a experiência que tive nesse e-commerce comecei a desenvolver mais essa biblioteca e este conceito de divisão de camadas e responsabilidades. Era primordial saber o que estava desenvolvendo nos projetos. Era um módulo complexo? era um módulo simples? esse módulo conversava com outros? ele cuidava de coisas maiores? tarefas menores?

A abstração é o maior bem de qualquer programador, é nela que consegue fazer com que a vida da sua aplicação faça sentido e seja harmônica. Então é muito importante abstrair. A conclusão disso é, eu não sabia o que estava criando. Quando eu criava um módulo AMD , eu não sabia o que aquilo era. Faltava abstração. Mas agora eu já tinha experiência e podia olhar de forma macro e podia dizer melhor como abstrair a minha aplicação.

O jails caminhou a partir disso, determinar o que era o que, na aplicação. Definir tarefas específicas, de forma que seja de fácil aprendizado, que reutilizasse coisas que já sabemos, e apenas nos guiasse para uma aplicação mais harmônica.

Teaser…

Há muito pra falar sobre o framework, mas se utilizar um post só vai ficar enorme, maior do que já está. Em resumo, o projeto chegou à um nível que considero satisfatório para ser usado em produção. Então queria divulgar nesse post, o meu beta release do Jails. =D

Ele está hoje na versão 0.7.8 e estou bem satisfeito do resultado. E o mais importante, ele é colaborativo, o fato de todos os componentes, módulos, aplicações serem modulares, isso possibilita que outras pessoas possam desenvolver coisas para o Jails sem precisar tocar no código fonte. Basta plugar nele e ver funcionar…

Eu aceito qualquer tipo de ajuda, documentação, componentes e módulos novos, com o site, pull requests, críticas e opiniões. Qualquer um pode fazer um componente reutilizável de forma muito muito fácil, e seria muito útil para a comunidade.

Ele já está disponível e pronto, mas ainda faltam alguns screencasts para ajudar a mostrar o quão fácil é usar. Se quiser fazer um fique à vontade e eu ficaria muito feliz com essa ajuda.

Volto para falar mais desse projeto em futuros posts, abaixo segue o projeto e um screencast sobre como fazer um componente no Jails.

E o principal… é um framework brasileiro.

Githubhttps://github.com/jails-org

Screencast: Jails – Componentes

 

 

 

 

 

Anúncios

5 comentários sobre “Jails – MVC + AMD, repensando a arquitetura Javascript.

  1. Graaaande Eduardo,

    Venho acompanhando seu dead blog há algum tempo. Realmente tem coisas muito interessantes, pena estar parado.

    Eu havia postado uma dúvida em 2014, mas nunca tive respostas…

    Você poderia me ajudar no meu questionamento sobre design pattern observer em JavaScript ?

    A dúvida está no post: https://javiani.wordpress.com/2010/05/22/design-pattern-observer-em-javascript/

    Ou abaixo:

    ola duas coisas: 1) o link com o código não esta mais acessível

    2) poderia me auxiliar , tenho um form com 3 input ( valor1 , valor 2, total) Eu gostaria de montar um exemplo usando observer pattern ao alterar o input valor1 ou valor2, automaticamente alterar o valor do input total.

    A idéia seria monitorar os inputs valor1 e valor2 e caso sofram alteração atualizar o input total.

    Você poderia fazer um demo disso em javascript? ficaria mais claro de entender e me ajudaria bastante.

    Obrigado pela ajuda.

    OBs: gostei do seu framework sobre jails. Só um porém, o termo JAILS, é largamente utilizado é difundido na comunidade FreeBSD. É utilizado para construção de máquinas filhas dentro de uma máquina mãe. O conceito baseia-se em ter uma máquina filha “enjaulada” dentro de uma máquina mãe. A finalidade serve para dividir servidores e serviços em uma mesma máquina facilitando o gerenciamento. Além disso o foco é em segurança, pois se a filha é invadida, a máquina mãe está sempre segura, bastando extrair uma cópia da máquina filha sem a necessidade de reinstalar toda a máquina mãe novamente.

    Pense assim, Você pode ter 1 máquina mãe, e dentro dela várias filhas, cada uma enjaulada e cada uma com seu próprio IP. No meu caso tenho 1 mãe, com umas 20 filhas. Uma filha só com mysql , outra só com www, outra só com email, outra com dns1, outra com dns2, etc

    Ou seja cada filha tem seu IP e funciona como um servidor real, dentro (enjaulado) em uma máquina mãe.

    Você não tem noção como isso facilita a administração, a segurança , backup, etc Pois tenho todos os serviços “isolados”, mas dentro do mesmo servidor.

    Esse é a conceito de jails, e fiz questionar lhe explicar, pois é amplamente difundido no mundo FreeBSD, e pode gerar dificuldades de encontrar seu projeto no Google pelo mesmo nome.

    >

    • E aí Manuel tudo bem?
      Muito obrigado pela explicação sobre o FreeBSD Jails eu tinha percebido da sua existência quando dei um search sobre o nome para saber se ia colidir com alguma outra biblioteca js. Não sabia sobre detalhes que explicou mas gostei do paradigma citado, sobre as mquinas filhas e seu relacionamento com a máquina mãe.

      Sobre o Observer, o tempo passa e a nossa cabeça muda muito. E por incrível que pareça a gente evolui. O observer apesar de ser bem didático e interessante não é necessário no js. A gente já trabalha efetivamente com eventos. No caso, hoje eu faria as coisas um pouco menos verbosa e mais simples usando pub&sub.

      O que deseja fazer é bem simples e se usa uma biblioteca como jQuery ou Zepto fica mais fácil ainda.


      var
      form = $('form'),
      inputs = $('input[name=valor1], input[name=valor2]'),
      total = $('input[name=total]');

      inputs.on('change', function(){ form.trigger('change'); }
      form.on('change', function(){ total.val( (+inputs.eq(0).val()) + (+inputs.eq(1).val()) );

      No seu exemplo um observer não tem muita serventia, porque basicamente utiliza eventos do dom.
      Um observer faz sentido em um ambiente onde não temos eventos, e precisamos criar um mecanismo que simule um.

      Acima eu usei um esquema pub&sub onde o form pode ser o seu observer, e os inputs são os seus notifiers. Toda vez que um dos campos mudar, eles notificam para o form que houve um evento ‘change’ e o form o escuta atualizando o campo total.

      Obrigado por seguir o blog mesmo que esteja bem parado. Talvez comece a fazer mais posts atualizando os posts antigos com o conhecimento que adquiri ao longo do tempo.

      O incrível é que faz um tempo já que fez a pergunta sobre seu esquema e ainda está pensando em fazer ahhahahahha. Eu não teria tanta paciência, à essa altura já havia tentado descobrir a resposta sozinho… sou muito ansioso… ahhahhaha.

      []’s

    • Caraca Felipe!! To ligado, vc sempre tá por aqui. ahahahhaah

      Nossa muito legal essa extensão, deu uma ótima idéia pra colocar algumas ferramentas de debug no repositorio, posso usar essa sua ? Vou apontar lá pro seu app e fazer referencia pra você.

      Muito foda…

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s