O que é Grails e como ele salva a plataforma JEE (além de lhe evitar o tédio)?

Se você chegou a esta página, é sinal de que tem pelo menos uma noção básica do que venha a ser Grails:  um framework/plataforma utilizada na construção de aplicações web. Porém, para desenvolvedores Java já acostumados com os frameworks atuais, como Struts, JSF, Facelets e outros, trata-se de algo mais do que mais um framework com o objetivo de facilitar a execução desta tarefa. Trata-se de uma mudança de paradigma.

Até o surgimento do Grails, a história do desenvolvimento de aplicações web na plataforma JEE pode ser dividida, basicamente, em dois momentos:

• A criação da plataforma Java Enterprise Edition em 1999
• A introdução do Struts, que foi o primeiro framework de sucesso para esta plataforma.
  Este segundo momento é importantíssimo, pois logo após a introdução do JEE, tornou-se claro que a maior dificuldade consistia no gerenciamento da complexidade das aplicações. Neste sentido, o Struts foi o salvador da pátria, ao aumentar significativamente a produtividade do desenvolvedor.

Após a introdução do Struts, outros frameworks foram surgindo, todos visando o mesmo objetivo: facilitar o desenvolvimento de aplicações web na plataforma JEE e, de um certo modo, se possível, superar o Struts. Dado que este foi um dos primeiros frameworks, a tarefa foi fácilmente cumprida.

Porém, após o surgimento de 298347203498234872634 frameworks, percebia-se nítidamente que, apesar de todos os avanços, os mesmos problemas voltavam a se repetir:

• Criar o ambiente de desenvolvimento normalmente consumia um tempo significativo
• Boa parte das tarefas repetitivas ainda eram executadas manualmente
• Não havia uma diretiva nítida a respeito de quais convenções seguir
• Com raríssimas excessões, a tarefa de configurar a aplicação foi se tornando cada vez mais complexa
• Os frameworks eram todos basicamente muito parecidos
• E o que considero mais importante: desenvolver aplicações web na plataforma Java foi se tornando cada vez mais tedioso.

A plataforma JEE como um todo, por sua vez, também apresentava um significativo aumento em sua complexidade, ao ponto de diversos desenvolvedores passarem a substituir parte de sua funcionalidade por ferramentas como o Spring e o Hibernate. Esta dupla aliás obteve tamanho sucesso que, na versão 5 da plataforma (que solucionou a maior parte dos problemas presentes até então) observa-se nítidamente a sua influência.

Eis que aos dois eventos citados anteriormente, surge um terceiro: Ruby on Rails (RoR): um banho de água fria para os desenvolvedores Java. De repente, uma linguagem que até então a maioria ignorava mostra um framework para desenvolvimento de aplicações web centenas de vezes mais produtivo do que todos os nossos frameworks java juntos. Naquele momento, pode-se dizer que Java como plataforma web era carta fora do baralho.

O que RoR nos trouxe:

• Uma aplicação prática do conceito de desenvolvimento baseado em convenções. Seguindo este paradigma, que basicamente nos diz: “olha, siga estas convenções que eu me viro com o resto”.
  É incrível pensar hoje que algo tão simples era negligenciado por desenvolvedores Java. Até então, as “convenções” que levavamos em consideração diziam respeito apenas aos nossos famigerados arquivos XML (e cada componente com as suas próprias “convenções”)

  (o “rails” do nome faz referência justamente ao uso de convenções, que correspondem aos “trilhos” seguidos pelo desenvolvedor no processo de desenvolvimento)

• Stack completo: ao contrário do que ocorre em Java, no qual para criar uma aplicação usamos n componentes como por exemplo Hibernate, Log4J, Xerces, Commons, Spring  e cia ilimitada, na qual passamos HORAS, e em certos casos, DIAS nos preocupando em como fazer com que tudo fique bem integrado, RoR trouxe uma série de componentes já pré integrados e prontos para uso. Ficar horas tentanto integrar componentes de uma hora para outra se tornou passado.
  O desenvolvedor só precisava se preocupar com a sua lógica de negócios, e não com uma infinidade de detalhes técnicos que só atrasam seu trabalho.
• Scaffolding: ao desenvolvermos uma aplicação web, boa parte do trabalho é repetitivo, como por exemplo a criação da camada de negócio (no caso de aplicações CRUD, isto se torna nítido) e controladores. Com RoR, o próprio framework, a partir de alguns modelos, cria para o desenvolvedor o esqueleto básico de sua camada de visualização e controle. Fica por conta do desenvolvedor apenas customizar estes arquivos de acordo com a necessidade de sua aplicação.(posteriormente neste trabalho irei mostrar que, na realidade, o scaffolding pode ser uma armadilha. Porém, por enquanto, vamos ver apenas o lado positivo do mesmo)
• Expansibilidade: em RoR é possível criar plugins que ampliem o poder do framework. Algo não lhe é atendido? Simples: crie um plugin. Apesar de já existir este recurso em diversos frameworks Java conhecidos, RoR conseguiu facilitar ainda mais a execução esta tarefa, elevando RoR do patamar de framework para o de plataforma.

Resumindo: RoR expunha a todos diversos dos problemas existentes no desenvolvimento de aplicações web usando a plataforma JEE. Estes eram simplesmente eram ignorados pela maior parte dos desenvolvedores, que até então os viam apenas como “ossos do ofício”.

Mas no caso da plataforma Java, que possui uma imensidão de bibliotecas existentes (a maior quantidade de biblioteca desenvolvida por terceiros na história) e código legado presente, como tirar proveito dos ganhos de produtividade obtidos pelo Ruby on Rails, um framework baseado em uma plataforma completamente diferente?

Duas foram as soluções:

1. Implementar o ruby em Java. Eis que surge o projeto JRuby. Problema: a sintaxe e o modo de trabalhar do Ruby é muito diferente daquele com o qual estavam habituados os programadores Java. Consequentemente, a curva de aprendizado é muito maior.
2. Implementar um framework baseado nos mesmos princípios do RoR na plataforma Java: surge o Grails.

Para o desenvolvedor Java acostumado aos frameworks até então, Grails se mostra completamente alienígena ao primeiro contato. Para começar, a linguagem usada não é Java, e sim Groovy. Por que Groovy?

• Possui uma sintaxe bem parecida com a do Java.
  Na realidade, Groovy resolve algumas inconveniências da linguagem Java de uma maneira bastante elegante.
• Trata-se de uma linguagem dinâmica. E linguagens dinâmicas, todos sabem, são bastante produtivas.
• É baseado na plataforma Java. Consequentemente, todo o código Java pré existente pode ser usado de forma transparente por código feito em Groovy. Não é preciso recompilar ou utilizar qualquer tipo de tradução, uma vez que código Groovy é compilado diretamente para bytecode.
  (aliás, código Java também acessa código Groovy diretamente, pois no fina das contas, estamos lidando apenas com bytecode!)
• É rápido. Código Groovy pode ser compilado, chegando a uma performance bem próxima (ou igual) a do código Java tradicional.
• Como o próprio nome já diz, é uma linguagem bem divertida de se usar. :)

Outra diferença diz respeito ao fato de se tratar de um ambiente completo de desenvolvimento. Ao baixar o Grails, o desenvolvedor já possuirá em sua máquina tudo o que precisa para começar a desenvolver suas aplicações. Traduzindo: Grails aposenta aquela velha história de ter de se ficar buscando arquivos jar na internet para se começar a trabalhar (no caso do Grails, isto é levado ao extremo. de cara o Grails já vem inclusive com seu próprio servidor de aplicações: o Jetty).

O ciclo de desenvolvimento também é bastante diferente. Ao desenvolvermos uma aplicação web usando JEE, normalmente o ciclo consiste em codificar, compilar, fazer o deploy da aplicação, testar e voltar a codificar. No caso do Grails, o ciclo consiste apenas em codificar, iniciar a aplicação e continuar alterando o código sem precisar ficar compilando e fazendo deploy o tempo inteiro (lembra muito o desenvolvimento em Lisp). Como resultado, o processo de desenvolvimento se torna MUITO mais agradável, aniquilando o tédio desta tarefa.

Sobre este guia

Este guia pretende ser o mais abrangente possível. Iremos ver desde o be-a-ba do Grails até tópicos mais avançados, como a criação de plugins e hacks que podemos aplicar ao framework.

Ao mesmo tempo, visto que não conheço Grails 100%, conto com a participação dos leitores em sua criação, razão pela qual estou disponibilizando o guia no formato de blog. Qualquer um poderá me enviar correções e novas informações a serem compartilhadas por todos.

Não há uma forma final para este texto e provavelmente jamais terá. Por estar em formato de blog,este  constantemente será alterado, tornando o conceito de edições no nosso caso completamente sem sentido (Guimarães Rosa adoraria ter um blog). Dado que a forma final jamais será cristalizada, o texto não precisa ser seguido linearmente. Ao consultar algum dos tópicos presentes, você será informado dos pré requisitos necessários à sua compreensão, resultando portanto em um cookbook no final das contas.

(um cookbook com linearidade proposta, definida pela ordem na qual vou escrevendo os capítulos do guia)

Como mencionei, iremos começar do básico. No próximo capítulo, pretendo expor como é feita a instalação do Grails. A partir deste ponto, iremos acompanhar o desenvolvimento de algumas aplicações, cada uma expondo detalhes do funcionamento do framework (e, claro, vocês poderão dar o pitaco que quiserem durante o processo).