Por que se importar com Grails? Esta é uma pergunta justa se formos levar em consideração a quantidade de frameworks com os quais desenvolvedores Java estão acostumados a trabalhar. Por trás desta pergunta na realidade há outra disfarçada: “Grails realmente trás algo de novo ou é só mais um framework?”.
Sou completamente a favor da diversidade, no entanto, se formos observar o histórico das ferramentas com as quais o desenvolvedor Java está acostumado, vemos que o único framework que realmente revolucionou as coisas foi o Struts. Não por ser a melhor coisa do mundo (nunca foi), mas pelo puro fato de ter sido o primeiro. Nese sentido, pode-se dizer que o desenvolvimento web na plataforma Java é antes e depois do Struts.
Após o Struts, o que se viu foi uma proliferação incrível (e saudável) de frameworks, todos prometendo “revolucionar o desenvolvimento de aplicações web aumentando a produtividade dos desenvolvedores“. De certo modo, muitos conseguiram (e MUITOS outros não), mas no final das contas, sempre ficava a impressão de que não traziam nada de realmente novo (com raras excessões, como o VRaptor, Tapestry, JSF e outros).
Sendo assim, a pergunta que fica é: seria Grails apenas mais um para a lista? E a resposta é: não. Isto porque Grails não trás consigo novas tecnologias (na realidade, é tudo baseado em tecnologias que já existiam), mas sim um novo modo de se trabalhar.
O modo de trabalhar no qual Ruby on Rails (RoR) é um dos pioneiros. Só para lembrar, o nome original do Grails era Groovy on Rails. Quando RoR apareceu, foi como um tapa na cara do desenvolvedor Java, pois do dia para a noite, aquele modo de trabalho com o qual estávamos acostumados a trabalhar de repente se mostrou incrívelmente improdutivo.
Do dia para a noite, ficaram nítidos alguns problemas que enfrentávamos diariamente e para os quais simplesmente torciamos o nariz:
Dificuldade em integrar componentes
Quem trabalha com Java sabe: temos ferramentas maravilhosas, como por exemplo Spring, Hibernate, Log4J, JUnit e muitas outras que realmente ampliam muito a nossa produtividade. Fazem maravilhas por nós, mas quando precisamos integrá-los, boa parte desta produtividade é simplesmente perdida.
O Spring nos ajudou a resolver estes problemas, mas no entanto ainda não era suficiente. A quantidade de arquivos jar com os quais precisávamos lidar é um problema. Quem nunca passou por problemas deste tipo que atire a primeira pedra.
Arquivos de configuração
Ao criarmos nossas aplicações, ficava nítido que boa parte do tempo era gasta trabalhando com arquivos de configuração. Configuração do servidor, das ações, dos managed beans, das tag libraries, dos componentes JSF, etc.
E todos escritos em XML, cuja sintaxe, apesar de bacana, é bem distante da qual os programadores estão acostumados. Tudo bem: há assistentes para estas tarefas, porém o confronto com os malditos é inevitável.
Repetição, repetição, repetição, repetição
Quando se está trabalhando com uma aplicação simples, que seja basicamente apenas CRUD, pode-se ver nítidamente o quão repetitivo o trabalho se torna. Você precisa de uma página para consultar registros no banco de dados, outra para criar novos registros, outra para editar estes registros e mais uma para visualizar os detalhes do mesmo. Resumindo: são basicamente 4 páginas por entidade. Logo, se sua aplicação possui N entidades, o número de páginas a serem geradas é no mínimo 4*N.
E sabe o que é mais engraçado? Em sua maior parte, as páginas são basicamente as mesmas. Só variam os campos. Não seria ótimo se estas já fossem geradas para você?
Ambiente de desenvolvimento complicado de ser configurado
Este é um problema comum: chega um novo desenvolvedor na sua equipe e é necessário que você crie ou configure seu ambiente de desenvolvimento. Há duas alternativas aqui: você já tem algo pré-configurado (só copia para a máquina cliente e pronto) ou tem de trabalhar do zero. No segundo caso, será preciso instalar IDE, bibliotecas, JDK, etc. E pior ainda: ainda precisa preparar o ambiente de desenvolvimento para que trabalhe direito com o seu framework (o que nos leva a primeira dificuldade). Tudo bem que você pode simplesmente instalar uma IDE como Netbeans ou Eclipse e teóricamente tudo já viria pré configurado. No entanto, as coisas não são tão lindas assim.
Ao se iniciar um novo projeto, é incrível quanto tempo se perde só para montar o ambiente…
O modo Ruby on Rails (e Grails) de se trabalhar
É importante mencionar que Ruby on Rails não é a solução para todos os seus problemas (assim como Grails), porém os princípios básicos por trás do seu funcionamento apontam diretamente para os problemas que mencionei acima:
DRY: Don’t Repeat Yourself
A pergunta que se coloca aqui é: se há tarefas repetitivas no processo de desenvolvimento, por que não deixar que o framework tome conta destas tarefas para você? Assim você se preocupa apenas com o que importa: o negócio a ser modelado.
No Ruby on Rails vimos ressurgir algo que até então haviamos simplesmente ignorado: o scaffolding. O framework gera automáticamente para o desenvolvedor arquivos pré prontos para as principais tarefas repetitivas, como por exemplo páginas de CRUD (inclusão, edição, listagem e visualização de detalhes) e controladores. O programador só precisa customizar estas páginas e pronto. E se quiser algo a mais, basta escrevê-las por si próprios!
(aonde você viu anteriormente o scaffolding? Nos bancos de dados pessoais como Access (maldito!), Paradox, FIleMaker e outros!)
Convenções sobre configurações (zero configuration)
E aqui é que a produtividade REALMENTE se faz nítida. Você não precisa de arquivos de configuração se tudo encontra-se em seu devido lugar. No caso do Grails e RoR, a partir de algumas convenções estipuladas pelo framework, o programador não precisa se preocupar com arquivos de configuração.
Por exemplo: em Grails, todos os controladores se encontram dentro de um diretório específico. Sendo assim, não é necessário criar um arquivo de configuração que os identifique. Ao ser iniciada, a própria aplicação já irá descobrir quais são os seus controladores.
O grande lance é: os arquivos de configuração são desnecessários porque a própria aplicação já é a sua configuração.
Porém, mais do que isto, deve-se pensar em convenções sobre configurações, e não ao invés de. Por que? Simples: porque aplicações feitas em sua maior parte para serem usadas no ambiente corporativo, sendo assim, precisam ser fácilmente integradas aos componentes pré-existentes. Nestes casos, o programador voltará a alterar arquivos de configuração, porém com uma intensidade bem menor do que a qual já se encontra acostumado.
(porém, na esmagadora maioria das vezes, o único arquivo de configuração com o qual você terá de enfrentar consiste no que configura o acesso a suas bases de dados (e não é um arquivo XML))
Stack completo
Assim como RoR, Grails já vem com o seu ambiente de desenvolvimento completo e padronizado. Você não precisa de uma IDE para começar a trabalhar com Grails. Basta o JDK e a instalação do Grails e pronto. Tudo já está disponível para você. Não é necessário se preocupar com a instalação do Spring, Hibernate, JUnit, Log4J, Commons, etc. A instalação do framework já vem com todos os componentes pré-configurados e prontos para uso.
Isto porque Grails é baseado em componentes com os quais já estamos acostumados e cuja eficácia é comprovada. No final das contas, Grails acaba sendo simplesmente uma fina camada que integra todos estes componentes para o desenvolvedor usando Groovy. É realmente fantástico.
Como resultado, você não precisa se preocupar com arquivos jar, configurações, etc. Já inicia o seu desenvolvimento pensando direto no que realmente interessa: o negócio a ser modelado. Resultado: produtividade instantânea.
E após esta explicação, e sabendo-se que existe o JRuby, a pergunta que fica é:
Por que Grails e não Ruby on Rails?
Na realidade, em ambos os casos o ganho do desenvolvedor será exatamente o mesmo. No entanto, para o programador Java, que já está acostumado com a sua sintaxe, Grails se mostra mais familiar, pois é baseado em Groovy, que no final das contas, possui quase a mesma sintaxe, diminuindo significativamente a curva de aprendizado.
Até o surgimento do JRuby, outro ponto importante em favor ao Grails consistia no fato de ser possível reaproveitar todo o seu código legado em uma aplicação Grails, porém este ponto ainda se mantém para ambos os casos.
Mas no final das contas, a escolha entre Grails ou Ruby on Rails pode ser resolvida com a seguinte pergunta: com qual linguagem você se sente mais à vontade? Groovy (Java) ou Ruby? Mais Java e Groovy? Grails é para você. Curte Ruby? Vá para o RoR!
Finalmente, respondendo à pergunta: por que se importar com Grails?
Após o lançamento do RoR, os problemas da plataforma JEE se tornaram nítidos. Mesmo que Grails não venha a ter futuro (pouquíssimo provável) e que RoR desapareça (mais improvável ainda), os frameworks que surgirão daqui para frente com certeza serão baseados neste “novo” modo de se trabalhar. E levando-se em consideração que Grails desde o início é feito pensando no desenvolvedor Java, é inegável que exercerá (e já exerce) uma influência significativa em tudo o que virmos surgir daqui pra frente.
Ou, resumindo: porque RoR e Grails de repente nos mostraram que nosso trabalho na plataforma JEE era incrívelmente chato.
Deixe uma resposta