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.
Muito bom este artigo sobre Grails, tirou algumas dúvidas que tinha em relação a este Framework, vou testar essa semana mesmo. Obrigado e parabéns pleo Blog
@janderson, Olá, eu também estou publicando (aos poucos, é verdade) um guia sobre Grails que pode ser acessado em http://guiagrails.itexto.com.br
Parabens pelo artigo, muito bom mesmo. Uma sugestao, acho que vc poderia pedir pra sites com mais audiencia (tipo br-linux – http://br-linux.org/indicar/) pra eles divulgarem o seu artigo, com isso muita gente que nao conhece grails pode ter a chance de conhecer e ajudaria muito a divulgar o grails. Valeu, e continue postando os seus otimos posts, pois ja acompanho o seu blog faz um bom tempo.
@Rogerio, Excelente idéia Rogério. Farei isto agora.
Excelente artigo, parabéns! Comecei a aprender a pouco tempo Ruby e Rails e pretendo depois aprender Groovy e Grails também.
Programo em Java a cerca de 2 anos e concordo com tudo que você relatou. Gosto da linguagem Java e também da plataforma, porém, acho que deveriam haver mais propostas visando simplificar o desenvolvimento. Pelo pouco que vi o Groovy parece uma boa alternativa nesse sentido.
@Frederico, não vejo Java com desenvolvimento complexo. Vejo sim, desenvolvimento Java para front-end com desenvolvimento complexo. Trabalhei 4 anos com Java no servidor, sem a camada visual, e depois mudei para camada web. Frustante levar uma semana pra deixar um fluxo de telas redondinho =(
Nunca mexi nem com Ruby ou Groovy, então posso falar besteira, mas o que eu pude compreender deles é que eles são muito bons para páginas CRUD, e sistemas com pouca interatividade com o usuário. E eu acho que o futuro da web está justamente na interatividade com o usuário.
Os sistemas devem ser ergonômicos o suficiente para serem auto-explicativos, sem precisarem de um manual, e a “técnica” CRUD falha nisso, pois pq cada ação do usuário é descontextualizada, sem uma sequência que faça sentido ao usuário. Dai vem a necessidade de um manual, um how-to, um faq, e isso só onera o processo de fabricação de um software.
O que eu queria dizer é que, acredito, falte às empresas visão. Tem muito gerente por ai que acha que fazer tudo CRUD é o canal, só pq ele não quer gastar um pouco a mais com um BOM web-designer, que pode modelar o sistema dele para algo mais dinâmico. Tem o papo de prazos, custos, bla, bla, bla, mas se o cliente pode negociar esse tipo de coisa, ele bem que pode demonstrar ao cliente as vantagens de ter um sistema assim…
bem, desculpa por usar o seu post para esse meu desabafo, mas acredito que uma coisa(+ umas cervejinhas) leve a outra
Mas, quero lhe parabenizar pelo post. Ficou bom.
@Limao, Olá, na realidade, Grails e RoR são excelentes para o CRUD, porque fazem o trabalho de macaco para o desenvolvedor.
No entanto, convém lembrar que CRUD normalmente é apenas uma ínfima parcela do que uma aplicação realmente precisa fazer. E é neste ponto que estes frameworks brilham, porque o desenvolvedor não precisa ficar perdendo tempo em um trabalho que, convenhamos, poderia ser feito até mesmo por um macaco, e assim pode se concentrar em aspectos BEM mais interessantes do que este, não é mesmo?
Com relação à falta de visão das empresas, novamente você está absolutamente correto. O principal problema é que normalmente os gestores acreditam que todo sistema deveria ser como uma planilha do Excel o que, infelizmente, não é possível (a não ser que você não queira fazer algo que realmente preste).
Exato! Pegaram no ponto chave. Coisas como criar um CRUD deveriam ser simples tanto em uma app web quanto em uma app desktop com Swing por exemplo. O que fosse além do CRUD, e em geral, dependendo do sistema é a maior parte do código, aí sim exigiria um esforço real de codificação compatível com sua complexidade. Trabalho com Swing desde que comecei com Java e há uns 8 meses com tecnologias web. O que pude observar é que após uns seis meses de experiência com desktop tínhamos criado um mini-framework pra facilitar nossa vida com Swing. Coisas como trabalhar com tabelas, listas, tratar eventos, impressão, binding de campos do formulário, etc. Desde então conseguimos construir CRUDs com muito mais produtividade. O que imagino é que poderiam existir coisas desse tipo nas próprias fundações do Swing, de forma parecida com que o Rails e o Grails fazem, configurando as bases da aplicação. Com certeza atrairia mais programadores novatos para o Java e deixaria todos com mais tempo pra se dedicar a outros aspectos importantes do desenvolvimento, como projetar modelos de domínio consistentes e se dedicar mais a atender as necessidades reais dos clientes.
@Frederico Já está sendo criado algo assim. Procure mais informações sobre o projeto Griffon, que é basicamente o Grails para Swing. Muito interessante!
Pingback: Framework Grails e o desenvolvedor Java
Cara que artigo Fantástico !
já to indo acessar o guia !
[]’s
O Link no br-linux – do Augusto- foi a grande chave pra chegar até aqui …
[]’s
@André Seoane, Opa. Obrigado André!
Excelente artigo cara. Voce explicou direitinho o q sempre tento explicar para desenvolvedores q nao conhecem o rails.
Parabens!
@Lucas Allan, Opa, Obrigado Lucas!
Muito bom o seu artigo, além de bem embasado, muito bem escrito. Parabéns.
@Tarcísio, Obrigado Tarcísio!
Henrique,
Existe uma coisa em desenvolvedores java, observo isso com os que trabalham comigo, parecem que gostam de sofrer, não sou conhecedor de grails nem ror, mas comentei com mesu colegas sobre os frameworks e eles olham com certo descredito ou com a visão da segurança que a plataforma j2ee oferece juntamente com suas IDE’s “maravilhosas”. Gerentes esperam produtividade, mas os “javistas” esperam que as ide’s incorporem o que oferece o grails para então reconhece-lo. De outro lado onde efetivamente temos grails aplicado? Que sites utilizam grails com suporte para seu desenvolvimento? Esta é uma curiosidade minha. O que me encantou em grails, foi o fato de ter me facilitado entendimento do padrão mvc, compreender o mecanismo de uma aplicação web, que até então via java não era claro (não sou desenvolvedor java, comecei em grande porte com cobol, natural etc, andei na plataforma baixa com cliper .. depois vb). Mas, vislumbro pontecial da ferramenta para o mundo java… e a até onde tenho visto vc é um grande entusiasta do grails espero que o tutorial avance. Em breve vou postar algumas dúvidas que tenho no curto tempo que possodedicar ao estudo do grails. Excelente artigo!!!>
Opa Luis. Eu concordo em grande parte com o que você diz. Na realidade, eu percebo um comportamento bem do tipo: “só é bom se for difícil” também. :)
Com relação a exemplos, dê uma olhada neste link: http://grails.org/Testimonials
Outro excelente exemplo é o site da Wired: http://www.wired.com
E também o da Sky norte-americana
http://www.sky.com
Eu, pessoalmente, tenho tido uma experiência maravilhosa com Grails. Tenho desenovlvido alguns projetos com ele (todos com grande quantidade de requisições e processamento) e, até o momento, consegui duas coisas fantásticas:
* Alta estabilidade
* Reaproveitamento total do meu código legado (pra mim, o mais importante dentro do ambiente corporativo)
Eu se fosse arquiteto dessa tua empresa te mandava pra rua. Onde ja se viu vir querer meter rails em ambiente corporativo? se nao der certo voce vai pagar o prejuizo do projeto? Acho que nao.
Java pelo menos é seguro, funciona integra com tudo quanto é coisa, tem webservices soap, tem integracao sap, cuidado cara voce nao tem experiencia suficiente pra dar estes pitacos, os caras estao corretos isso envolve DINHEIRO nao é brinquedo fazer sistemas.
Oi de novo J. Carlos.
Pelo visto você ainda tá confundindo Rails com Grails, certo? Vou supor que você esteja falando sobre Grails. Caso seja o contrário, me desculpe, ok?
Se você fosse meu chefe (graças a Deus não é nem nunca vai ser :) ) e me demitisse por esta razão, acabaria gerando uma situação bastante desagradável, pois eu procuraria o seu superior (caso existisse) e mostraria meus argumentos. Ele bateria com os seus, veria a sua ignorância sobre este assunto.
Agora, sobre os aspectos que você cita.
1. Groovy é Java: é executado na JVM e tira proveito dos mesmos recursos que o Java. Já te disse no outro comentário que é completamente compatível né?
2. Groovy e Grails também tem acesso a webservices soap, integração com SAP e tudo mais que você consegue fazer com Java. Simples assim: se tiver lido meu texto direito, vai ver que falo inclusive sobre a possibilidade de reaproveitar de forma transparente todo o código Java já existente. Leu isto?
Sobre ter ou não experiência. Você pode checar o meu currículo se quiser: http://www.linkedin.com/in/kicolobo
Cara, tive a oportunidade de começar a trabalhar com ROR e decidi ler sobre antes de me aventurar, seu post foi super esclarecedor.
grato
Kiko, vc novamente “botando p voar as banda”. Excelente artigo. Trabalhei com Grails em produção de larga escala e é chuchu com toddy. Mudei de empresa e estou trabalhando com JSP puro (o que p mim está servindo o aprendizado, pois sempre trabalhei com um framework fazendo o trabalho sujo para mim). Tenho planos de evangelizar a equipe aqui com grails. Também conheço RoR (e por sinal acho a sintaxe fantástica, até mais intuitiva do que Grails). Algumas pessoas que conheço que trabalham com RoR sempre comentam que o motivo da escolha pela tecnologia foi a Comunidade Ruby, que é bastante ativa.
Estamos em 2014, já se passaram alguns anos e Ruby on Rails em franca decadencia por nao ter aceitacao no mercado corporativo.
Pra que aprender uma plataforma que simplesmente NAO TEM DEMANDA isso nao só no Brasil mas é no mundo inteiro. Pra que? Só pra perder tempo ou fazer trabalho de faculdade?
Estudem um pouco verao porque Java e .Net chutam pra longe a maioria destas linguagens e plataformas pra fazer sistema de padaria.
Trabalho com isso tem mais de 10 anos, nao confio em qualquer coisa pra sistemas de largo prazo que vao permanecer rodando 24/7 em aplicacoes de missao critica. Queria ver a cara do twitter quando descobriu que fizeram a escolha errada.
Pra terminar a conversa esse lixo nao roda em WEBLOGIC ou seja isso ano serve pra nada a nao ser perder meu tempo!
Oi J. Carlos,
você está falando de Ruby on Rails ou Grails?
Se for Grails, há alguns problemas no que você está dizendo.
1. Há bastante demanda por Grails no país: eu, por exemplo, tenho recebido um número de pedidos de consultoria bem maior conforme o tempo passa. No exterior então a demanda é ainda maior. Então não bate.
2. Na realidade Grails executa em WebLogic sim. Desde a versão 1.0. Alguns anos atrás trabalhei em um projeto para a Oi, baseado na versão 1.0 do framework (Grails) e executava sem problemas neste servidor de aplicações.
3. Grails é executado na plataforma Java e usa código Java assim como se fosse escrito em Java mesmo. Groovy é uma linguagem que é executada na JVM e é 100% compatível com o Java. Então, este não é o problema.
4. Sobre aplicações corporativas: uma aplicação Grails é na realidade uma aplicação Java EE como qualquer outra. A diferença está apenas na linguagem que você usa: Groovy ao invés de Grails. Sobre Groovy, volte para o ponto 3 deste comentário, ok?
Para de ser retardado cara.
Pelo amor de Deus, quanta merda para um ser só.
@j carlos
Bom Dia Kico,
Muito esclarecedor seu post, direto e objetivo.
não responde mais esse “@j carlos”, ele deve ter alguma deficiência,
comentários evasivos.
Abraços.