Revista /dev/All

Nestes últimos anos na itexto trabalhamos com diversas tecnologias e no processo coletamos algumas estatísticas interessantes sobre estas: surpreendentemente (não pra mim), quem fica no topo quando o assunto é produtividade e qualidade é ele, o Grails.

Este post inicia uma série na qual falarei um pouco sobre aquele que tem sido o framework para desenvolvimento web mais poderoso com o qual trabalhei em minha carreira, o Grails. Dado que pode ser uma série longa, creio que seja importante primeiro entender como chegamos à situação atual.

O público inicial são pessoas que já tenham trabalhado com o framework. Entretanto, se você tem apenas curiosidade a respeito, vêm comigo por que será uma longa jornada e ao final (ou no meio) você terá uma poderosa ferramenta no seu cinto de utilidades.

Mas o que é?

É um framework full stack para o desenvolvimento de aplicações web baseado na linguagem Groovy. Esta frase inócua esconde seu real valor. 

Pra começar, é baseado em Groovy, que muito provavelmente ainda é a linguagem mais amigável e produtiva que exitse dentro da JVM. Quem conhece a linguagem há de concordar comigo: é o Java ++.  E o fato de ter esta base nos fornece o grande ganho do framework: sua altíssima produtividade.

Em segundo lugar, baseia-se em componentes testados pelo mercado: Spring Boot, Hibernate, Apache Commons e mais uma série de bibliotecas cuja qualidade já está pra lá de comprovada.

Mas não é apenas a ligação de componentes já existentes: Grails criou uma camada de abstração sobre estes que, aliada à já mencionada qualidade destas bibliotecas, também nos propicia um modo de trabalho muito mais eficiente, organizado e seguro.

E por ser full stack, também nos fornece algo importantíssimo, especialmente hoje em dia em que a quantidade de projetos a serem iniciados é bem maior: você tem o ambiente de desenvolvimento completo configurado em questão de segundos, o que pode ser vital, especialmente se formos pensar em micro-serviços.

Nos próximos posts vou falar mais sobre Grails, neste momento creio que seja fundamental começar por sua história.

Minha história com Grails

É longa: comecei em 2008 (talvez 2007) com Grails, se não me engano, antes mesmo da versão 1.0 do framework, que foi criado como uma cópia do Ruby on Rails (se chamava Groovy on Rails), só que voltada para a plataforma Java. 

Se me perguntassem em 2005 (?) qual o futuro do desenvolvimento web com certeza eu diria JSF (o 1.0 ainda). Mas alguns meses depois eu me sentiria bastante idiota, especialmente após ver a demonstração do Ruby on Rails feita pelo DHH.

Lembro de terminar de assistir o vídeo e pensar: “JSF é uma merda”. Literalmente isto, minha visão mudou radicalmente. Então, por que não adotar Ruby on Rails aonde eu estagiava? E tentei.

E deu certo no primeiro momento, rapidamente criei as páginas de cadastro que precisava com o framework, listei os registros todos que queria e boom: todo mundo ficou de boca aberta quando viram o resultado. No entanto, quando contei aos programadores que havia feito em Ruby, e que não estava usando nosso código legado em Java o fascínio se transformou em ódio e tive de voltar para o… bem, JSF, que agora me parecia tão terrível.

Na época, trabalhando com engenharia, lembro de precisar escrever alguns cálculos em meus programas usando a classe BigDecimal do Java. Era “ótimo” escrever uma fórmula como a de Bhaskara, por exemplo.

b.multiply(new BigDecimal(-1)).sqrt(b.multiply(b).minus(new BigDecimal(4).multiply(a).multiply(c)).divide(new BigDecimal(2).multiply(a)) // aposto que tá errada

Mas já conhecia outras linguagens na JVM, dentre elas uma chamada Groovy, que finalmente me permitia escrever algo como…

(-b + Math.sqrt(b*b - 4*a*c))/(2*a)

E assim Groovy entrou na minha vida, não como algo que eu usava para criar aplicações web com Grails (que sequer conhecia), mas sim como um alívio das dificuldades que sentia na época com o Java (ainda usava o 1.4  e o 1.5 estava começando a entrar em cena).

Com o passar do tempo descobri que podia também embarcar Groovy em meus projetos Java. E com isto meus usuários podiam ampliar o comportamento dos meus projetos escrevendo seus próprios scripts. Então Groovy se tornou pra mim uma espécie de “personal VBA“. Quando descobri que podia escrever uma DSL com Groovy então… tive orgasmos múltiplos como programador.

Mas o desenvolvimento web ainda me frustrava. Eu era um “programador desktop”. Se você já programou aplicações desktop com Delphi ou VB, vai me entender. São plataformas de desenvolvimento extremamente produtivas, bem feitas, bem pensadas. O contrário da web naquele tempo (e ainda hoje na minha opinião).

E depois da apresentação do DHH, não me sentia mais feliz com o modo como programava. Me sentia um idiota tentando criar componentes em JSF ou aprendendo Struts (alguém lembra dele?). Foi quando por acaso, lá por 2007/2008, ouvi falar de Grails.

Era o Ruby on Rails, mas com Groovy. E usando de forma transparente todo meu código Java. E eu ainda podia copiar meus arquivos JAR para a pasta lib (ou mesmo arquivos .java para a pasta src/java) do projeto e ter reaproveitamento TOTAL do meu código legado. Pronto: agora sim conseguia convencer o pessoal a usar outra coisa. E consegui.

De lá pra cá já foram 10 anos, e pude acompanhar a evolução do framework. O que interessa da minha história acaba aqui. Vamos para a do Grails.

Talvez o único ponto necessário seja que em 2008 criei o Grails Brasil (http://www.grailsbrasil.com.br) , que atualmente é ainda a maior comunidade de desenvolvedores Groovy e Grails do mundo em número de participantes (e que também escrevi um livro a respeito).

História do Grails

A trajetória do Grails é bastante interessante e me lembr auma parábola, na qual há grande animação no início, um desânimo no meio e uma retomada ao final. 

A versão 1

As versões 1.0 a 1.3.9 do Grails foram as que mais me impactaram. Não eram perfeitas, tinham uma quantidade imensa de bugs, o que tornava o upgrade do framework algo vital de ser feito esporadicamente em nossos projetos. Entretanto, mesmo com todos estes problemas ainda era um bom negócio (minto, um excelente negócio).

Nesta época frameworks full stack ainda faziam todo o sentido. O desenvolvimento web ainda tentava imitar o desktop (ficava nítido quando você via aquelas páginas que buscavam simular menus drop down, por exemplo) e você queria fazer tudo em um único pacote.

E o Grails era ótimo por que, apesar de ter problemas no framework, era baseado em gigantes de qualidade já há muito comprovada: Spring e Hibernate. Então você conseguia conviver com os problemas, mesmo por que sempre havia um novo upgrade e realizá-los nos projetos era algo muito tranquilo (grails upgrade [número da versão]).

Também proliferaram diversos plugins, o que nos permitia enriquecer rapidamente o projeto. Lembro do antigo projeto Acegi, por exemplo, que depois virou o Spring Security, ou mesmo outros plugins incríveis, que geravam PDF a partir das páginas. 

O mundo também era mais simples: o termo “informática” fazia sentido e os sistemas eram, em sua maioria, meros cadastros. Como conseguíamos criar cadastros rapidamente com Grails (e cadastros facilmente customizáveis, sem qualquer tipo de limitação), tínhamos ali uma mina de ouro.

E houve hype: tanto é que o período de maior crescimento do Grails Brasil foi justamente na época das versões 1.0. E muitos desenvolvedores Ruby on Rails vieram para o Java graças ao Grails, que atuava como uma ponte para esta plateia. 

Lá pra versão 1.3.5 começou a história de que sairia uma versão 2.0 bem mais moderna e interessante. O cenário parecia bastante atraente. 

Grails 2.0 – um super upgrade

A versão 2.0 prometeu um enorme upgrade para o framework. E cumpriu este objetivo, no entanto para mim foi também a época mais desinteressante.

O framework estava agora consolidado, e este novo release trouxe uma estabilidade bastante interessante para a plataforma. Uma vantagem maravilhosa foi o fato da esmagadora maioria dos plugins da versão 1.0 funcionarem na 2.0. Então a migração ficava muito mais tranquila. Quase todo mundo realizou a migração: os poucos casos que não o fizeram foram justamente devido a incompatibilidade dos plugins.

A interface de linha de comando também sofreu melhorias brutais. Era muito mais eficiente. Além disto havia um suporte muito interessante das IDEs: Netbeans e Eclipse (distribuição Groovy e Grails Tool Suite) eram bastante satisfatórias.

A documentação também estava melhor, enfim, tudo estava melhor. Era claramente fruto do investimento da Pivotal no framework. Mas nem tudo era perfeito.

Pra começar o Grails 2.0 jogou fora aquela que, na minha opinião, foi a maior oportunidade perdida da história da plataforma Java: OSGi.

A oportunidade perdida: OSGi

Muito provavelmente você nunca ouviu falar em OSGi, mas é algo que existe desde 1999. Trata-se de uma solução de modularização do Java que nos permite construir soluções totalmente modulares (e dinamicamente modulares, o que é mais interessante).

Sua aplicação é composta por bundles, cada qual representando um módulo da mesma, que você pode, em teoria, habilitar, desabilitar ou realizar o upgrade individualmente com o sistema em execução.

Se você usa o Eclipse, trabalha com OSGi. Todo plugin da IDE é um bundle, e a própria IDE é provavelmente a aplicação mais popular da tecnologia. E havia a ideia de que plugins Grails seriam na realidade bundles OSGi.

Apenas imagine: você poderia escrever aplicações suscetíveis de terem novas funcionalidades acrescidas com esta ainda em execução. Ou mesmo resolver bugs substituindo plugins a quente. 

Na época do Grails 2.0 (2011, 2012) OSGi já não era mais tida como uma tecnologia de hype. Então o que decidiram fazer? Ignorar a ideia. Se esta ideia tivesse sido seguida, tenho certeza de que a tecnologia OSGi teria se popularizado.

(Com o passar do tempo OSGi acabou se mostrando uma solução bem mais complexa que o necessário e hoje, inclusive, o considero quase irrelevante)

A saída da Pivotal

Um grande susto foi a saída da Pivotal, que decidiu parar de investir nos projetos Groovy e Grails. Lembro que na época o medo se instaurou de que este seria o fim destas tecnologias.

Minha previsão na época se mostrou correta: não houve quase impacto algum no desenvolvimento do framework. Na realidade, houve uma baixa importante. Cessou o desenvolvimento do Groovy e Grails Tool Suite, que era uma das melhores IDEs para o desenvolvimento no framework na época.

E também, meses depois entrou a OCI na jogada, que acabou desempenhando um papel bem mais efetivo no desenvolvimento do framework no Grails 3.0.

Grails 3.0 – garantindo o futuro

Foi a versão que livrou o framework da irrelevância, e a primeira sobre a tutela da OCI. De longe foi a que trouxe os maiores avanços. Mas primeiro, vamos falar um pouco sobre o risco da irrelevância.

Em 2015 estava nítido que frameworks do tipo fullstack com renderização 100% baseada no servidor estavam com os dias contados. O modelo de desenvolvimento no qual temos uma API de um lado e um cliente em HTML 5 do outro já havia mostrado seu valor. E a esmagadora maioria dos desenvolvedores ainda via Grails como uma solução fullstack.

(esta mudança ficou muito clara em mim no decorrer do tempo: em um primeiro momento não aceitava a ideia de que teria o desenvolvimento dos meus projetos em pelo menos dois módulos (API e Frontend) ao invés de um único, tal como era o padrão no Grails.
Entretanto, economicamente (e isto requer um post a parte), esta realidade acabou se impondo)

A solução se deu através do conceito de profiles. Agora, se você quisesse usar o Grails apenas para desenvolver sua API, era possível (antes também era, mas mais trabalhoso). Agora você pode usar apenas o que quer do Grails, que ainda é, na minha opinião o framework mais produtivo se você quer desenvolver uma API web na plataforma Java.

Outra questão importante: na ausência de boas IDEs gratuitas para lidar com o framework, optaram por trocar o mecanismo de build. Saiu o antigo Gant e entrou em seu lugar o Gradle.

Esta mudança fez toda a diferença: de repente integrar Grails com outras ferramentas, tais como Jenkins ou outras IDEs se tornou um procedimento trivial. 

E se a versão 2.x já havia sido um boom de melhoria, a 3.x trouxe um salto ainda maior. Não me lembro de ter topado com um bug sequer do Grails nesta família de versões. 

Spring boot

Assim como o Grails 3 evitou a irrelevância do framework, na minha opinião o Spring Boot fez o mesmo trabalho para o Spring. E sabe o que é mais legal? Assim como o Grails original era baseado em Spring, o Grails 3 na realidade é uma aplicação Spring Boot.

E isto trás pro Grails todas as vantagens do Boot. Podemos usar os mesmos recursos de auto configuração e, ainda mais importante: as inovações do Boot automaticamente são transportadas para o Grails.

Temos então aqui as duas inovações que justificam o upgrade: um novo motor (o Boot) e uma integração muito maior com o mundo externo provida pelo Gradle. 

Novos sub-projetos

Um fato importantíssimo marca a família 3 do Grails: o início da sua fragmentação em sub-projetos. Hoje o GORM (framework de persistência) e o GSP (a solução de renderização de views, alternativa ao JSP do Grails) são projetos independentes, e que podem ser usados em outros projetos que não sejam baseados em Grails.

Isto abriu inúmeras portas: se você tiver, por exemplo, um projeto escrito em Groovy.

A perda dos plugins legados

Se você acessar hoje a seção do site oficial do Grails relativa a plugins irá ver que esta é dividida em duas partes: os plugins para as versões 1 a 2 do Grails e aqueles para a versão 3.

Com mudanças tão brutais no core do framework (Boot e Gradle), os plugins criados para as versões 1 e 2 do Grails se tornaram incompatíveis com a versão 3.0. E esta, na minha opinião, foi uma perda quase fatal.

Isto por que com o passar do tempo criou-se uma quantidade enorme de plugins para o framework. De repente tivemos de reconstruir toda esta riqueza do zero. E isto teve seu preço: e bem alto.

Há muitos projetos hoje que não podem ser atualizados para a última versão do Grails justamente por dependerem de plugins antigos. Existem hoje mais de  1250 plugins para Grails 1/2, e apenas 247 para o Grails 3.

Tudo bem que grande parte daqueles plugins foi se tornando inútil com o tempo, ou mesmo deixaram de ser mantidos, mas era uma comunidade rica. E muito se perdeu ali.

Hoje e amanhã

Não acredito que Grails venha a ser tão popular quanto o Spring ou outros frameworks (do ponto de vista mais egoísta, esta é inclusive uma vantagem comercial para nós), realmente o vemos como uma arma secreta que nos fornece produtividade muito superior à que temos com outros frameworks aliada à mesmíssima qualidade (isto quando não é superior).

É nossa arma secreta com um fator bastante importante: se consagrou com o tempo e que não desaparecerá nos próximos cinco anos pelo menos, o que fica evidente pela constante evolução do próprio framework e o lançamento de novos releases.

Ao médio prazo, especialmente após a chegada dos profiles, que nos permitem criar APIs isoladas, é inclusive um forte concorrente ao próprio Spring Boot. Mas isto só ficará claro para os que não conhecem o framework nos próximos posts.

Para saber mais

Talvez este post tenha lhe aguçado a curiosidade sobre o assunto. Seguem então algumas fontes interessantes:

• Grails Brasil – http://www.grailsbrasil.com.br 
• Meu blog pessoal – https://devkico.itexto.com.br
• O site oficial do framework – http://grails.org 
• O site oficial da linguagem Groovy – http://groovy-lang.org