De todos os frameworks web que já usei (Java ou não) de longe Grails é o meu favorito. É a plataforma Java Enterprise Edition como sempre deveria ter sido: simples, direta, fácil de usar e sem burocracia. Mas sabe de uma coisa? Adoro um Grails “mutilado”!
Eu sei: soa estranho, mas eu não uso todo o stack do Grails. Ignoro o GORM, que é a camada de persistência. E o scaffolding, razão pela qual muitos se apaixonam pelo framework eu simplesmente abomino. E quer saber de mais uma coisa? Só uso 2 plugins: jQuery e Quartz. Conforme fui me aprofundando no framework acabei desenvolvendo uma maneira própria de trabalhar com ele. E é justamente este o assunto deste post.
O que é lindo no Grails: o fato de ser Java
O mais legal é o fato de ser baseado em Groovy. A fórmula é simples: se é Groovy, é Java. Tudo aquilo que você está acostumado a fazer em Java pode ser feito quase que da mesma forma com Groovy. Na realidade: da pra fazer de formas ainda mais legais. O acesso ao código legado (o que inclui todas as suas bibliotecas e frameworks favoritos) de forma transparente funciona como se fosse uma “fonte da juventude” para todo aquele amontoado de código que muitas vezes adquire com o tempo uma certa aura de tediosidade. Como já disse antes, Grails tira a plataforma JEE do marasmo.
Lembre-se disto: Groovy é Java. Ao trabalhar com Grails, você não precisa usar só os plugins oferecidos para o framework. Você pode e deve ir além. Se quiser pular o resto deste post, tenha apenas isto em mente.
MVC como lei: o problema com Grails
No meu caso é muito comum precisar escrever uma aplicação que será executada em diversos ambientes diferentes usando a mesma lógica de negócio. Até ai, tudo bem: eu poderia centralizar minha lógica de negócios em um servidor de aplicações e em seguida simplesmente implementar uma série de clientes, certo? Infelizmente apenas em condições ideais de temperatura e pressão.
Muitas vezes um cliente quer uma versão desktop de uma aplicação web que eu já tenha desenvolvido, ou mesmo o contrário. E em um número assustadoramente grande de vezes eu sequer posso contar com um servidor de aplicações (ainda não estamos no paraíso). Nestes casos a única constante computacional que possuo (quando dou sorte) é o SGBD. No meu caso reaproveitamento se torna uma questão de sobrevivência.
A solução que encontrei se chama Spring. Com ele tenho quase todos os recursos que obteria com EJB sem a necessidade de um servidor de aplicações e, o que é ainda melhor: tornando meu código Java realmente móvel. Basta que eu o empacote tudo o que eu preciso em arquivos jar e em seguida os reaproveite no ambiente de execução em questão: web, desktop ou seja lá o que for.
É exatamente por esta razão – a necessidade de reaproveitamento de código – que em 99% das vezes uso XML ao invés de anotações pra configurar o Spring ou o Hibernate. XML eu externalizo fácil fora dos meus arquivos .jar: anotações não.
O problema do reaproveitamento de código Grails
Grails me trás um único inconveniente: se você desenvolve algo 100% baseado no framework, o reaproveitamento do código gerado fora do Grails se mostra bem complicado. Resumindo: jogar seu código Java dentro de um projeto Grails é maravilhosamente simples: basta copiar todos os arquivos jar necessários para o diretório lib da sua aplicação. No entanto, se você escreve sua lógica de negócio usando como base componentes de infraestrutura do Grails como o GORM, por exemplo, reaproveitar seu código Groovy fora da plataforma Grails se mostra tarefa práticamente impossível.
O único modo eficiente que conheço de reaproveitar código 100% baseado em Grails é através da criação de plugins. Infelizmente seu plugin só poderá ser executado em outro projeto Grails (pelo menos por enquanto). Apesar de desde a versão 1.2 (ou seria a 1.1?) dizerem ser possível usar o GORM fora do Grails, eu nunca o consegui nem conheci alguém que tivesse obtido sucesso nesta tarefa (se você obteve, por favor, me conte como fez ok?).
Como resolvo a questão
Simplesmente não uso o GORM. Ao iniciar um novo projeto em Grails que vá usar meu código legado, a primeira coisa que faço é desinstalar o plugin do Hibernate. Assim não tenho sequer a tentação de criar uma ou outra classe de domínio que seja persistida com o GORM. Na prática, a única vantagem do GORM – ao menos pra mim – sempre foi a criação de finders dinâmicos e o modo como as classes de domínio são mapeadas para o banco de dados.
Mas sabe de uma coisa? Percebi que raramente uso finders dinâmicos! Sendo assim, no meu caso vale muito à pena sacrificar uma funcionalidade que eu raríssimas vezes uso por uma maior mobilidade do meu código fonte.
Toda a minha camada de negócio é implementada fora do Grails. Normalmente é escrita usando Java, Groovy ou, mais recentemente, Clojure. Sempre sem qualquer dependência direta com qualquer componente de infra-estruura do Grails.
Resumindo: o Grails deixa de ser um framework full stack no meu caso e passa a ser o responsável apenas pela camada de visualização e controle.
Mas sem o GORM, o que Grails tem de bacana? Tudo!
Mesmo sem ser usado como um framework fullstack, Grails ainda se mostra o meu framework web favorito. GSP é uma das tecnologias mais bacanas com as quais já trabalhei. Isto porquê diversas das tarefas chatas de serem feitas na plataforma JEE se mostram ridiculamente simples em Grails. Só para citar algumas: criação de tags customizadas e implementação de filtros.
Além disto, o modo como criamos controladores com Grails é o mais elegante que já encontrei. Muito mais fácil de se trabalhar do que com JSF ou Struts por exemplo. É direto, simples, sem burocracia. Eu posso me focar só no que o controlador tem de fazer e o que é ainda mais interessante: dentro deste tratar meu código Java como se fosse Groovy!
Scaffolding
Muita gente se apaixona pelo Grails ao ver o scaffolding em funcionamento. O problema é que muitos acabam se esquecendo de um fato básico: scaffolding em inglês significa andaime. O que é um andaime? É uma estrutura que usamos como apoio ao construir alguma coisa, não é o objetivo buscado.
Vejo muitos iniciantes acharem que só podem executar determinada tarefa em Grails se o scaffolding oferecer recurso para tal. Bom: sendo assim sua aplicação só poderá incluir, editar, excluir e listar registros no banco de dados. Se este é o objetivo do seu projeto, vá fundo! O problema é que sua aplicação corresponde a apenas 0,01% dos casos reais. Ainda bem, pois caso contrário desenvolver sistemas seria tarefa executada por macacos.
Como não sou um macaco e o CRUD básico gerado pelo scaffolding do Grails no meu caso é desnecessário – pois sempre estou reaproveitando meu código legado – simplesmente o ignoro, mutilando assim mais um membro do Grails.
Plugins
A idéia do plugin é maravilhosa. É o reaproveitamento de código no qual “nada pode dar errado“, visto que, ao menos em teoria, trata-se de um projeto já bastante testado, com qualidade excelente e que lhe poupará um tempo enorme, pois te livra do trabalho de precisar reinventar a roda. Infelizmente nem tudo são flores.
De todos os plugins não desenvolvidos por mim ou pela minha equipe, acabei ficando com apenas dois: jQuery e Quartz. Antes de construir uma aplicação lotada de plugins, sempre levo em consideração o seguinte:
Aumento acidental do déficit técnico – Sejamos honestos: quantas vezes você chegou a ler (e entender) o código fonte dos plugins que usa em seus projetos? Caso encontre um bug no seu plugin favorito e seu deadline esteja curto, você tem certeza de que conseguirá em tempo hábil resolver o bug deste componente ou encontrar uma solução alternativa de qualidade? Minha solução para este problema é simples: se for para usar um plugin, só opto por ele se já tiver um bom histórico por trás, ou seja, ignoro qualquer plugin que ainda esteja na sua primeira revisão e que tenha sido pouco usado pela comunidade.
Problemas de compatibildiade – Quem trabalha com Grails tem de estar preparado paraa atualizar o framework sempre que seja lançado um novo release. Convenhamos: apesar de ser um framework maravilhoso, ainda possui um BOM número de bugs. É vital que seu projeto esteja com a última versão do Grails. Agora: e se o seu plugin for incompatível com o último release o que você faz? Chora? Espera que o autor do plugin encontre uma solução para o problema?
Aumento do número de dependências – É fato. Seu projeto agora depende de código que só estará sob seu domínio se, e somente se, você tiver conhecimento completo sobre seu funcionamento. Ao optar pelo uso de um plugin, tenha sempre em mãos o código fonte usado e, ainda mais importante: compreenda-o.
Resumindo: plugins são uma das boas coisas da vida. Sendo assim você precisa tratá-lo como tal, ou seja, com EXTREMA moderação. Não estou sozinho na minha opinião sobre plugins. DHH tem uma visão bastante similar.
(e antes que digam: não estou dizendo que os únicos plugins bons são o jQuery e o Quartz)
Concluindo
Grails é maravilhoso. Este framework revitalizou meu código legado de uma forma que até então eu não podia sequer sonhar. Quando Ruby on Rails surgiu e se tornou popular, ficou claro que o modo como estavamos desenvolvendo aplicações para a plataforma JEE tinha algo de muito errado. O problema é que muitos desenvolvedores – como eu – já tinham uma quantidade significativa de código legado de qualidade, ou seja, testado e funcionando perfeitamente (ou quase :) ) e não podiam se dar ao luxo de ter o retrabalho de implementar novamente em outra linguagem. Legado só é negativo quando é de má qualidade e você é obrigado a conviver com ele.
Quando conheci Grails foi um alívio imenso porque de repente eu podia escrever aplicações como em Ruby on Rails dentro da plataforma Java sem precisar reescrever nada do que já estava pronto. E o que era melhor: de uma forma muito produtiva, porque até a minha curva de aprendizado era menor. Afinal de contas, eu ainda podia contar com as mesmas bibliotecas com as quais adorava trabalhar, como por exemplo as do projeto Apache Commons.
Meu conselho para quem estiver inicando em Grails é o seguinte: se for um projeto novo, criado a partir do zero e que só será executado em um ambiente computacional, no caso, web: use e abuse dos recursos oferecidos pelo framework. Se puder sempre contar com um servidor de aplicações para este projeto e seus derivados não se assuste com os problemas de mobilidade de código que mencionei acima: você pode implementar interfaces REST ou baseadas em WS com Grails de uma maneira maravilhosamente simples.
Agora: se você possui código legado de qualidade, ou sabe que alguns componentes do seu projeto deverão ser executados em ambientes diversos, implemente-os de forma completamente independente do Grails.
De uma forma ou de outra você sairá ganhando porque a produtividade do Grails – mesmo mutilado – é simplesmente fantástica. O mais importante a ser lembrado é o seguinte: você não programa em Grails, mas sim em alguma linguagem de programação executada na JVM. Sua plataforma não é – nem deve ser – o framework, mas a JVM. Tire proveito disto!
Leitura complementar
Joel Spolsky tem um artigo chamado “Things You Should Never Do – Part I” que é justamente sobre o perigo de se reescrever código do zero, e como isto pode destruir a sua empresa. Concordo com o autor, cujo texto pode ser lido aqui: http://www.joelonsoftware.com/articles/fog0000000069.html
Deixe uma resposta