Um Benchmark para Grails e Ruby on Rails, e escalabilidade

Nesta semana o líder do projeto Grails, Graeme Rocher, criou um benchmark para comparar a performance de uma aplicação implementada com Grails e com Rails. O resultado inicial demonstra uma performance melhor para o Grails. Os resultados podem ser vistos aqui.

Ainda acho cedo para chegar a conclusões com 100% de certeza, vamos aguardar o pessoal do Rails se pronunciar. Acredito que o objetivo não foi o de se vangloriar em relação ao Rails, mas apenas o de mostrar para a própria comunidade Grails que o framework tem uma performance bem razoável.

É interessante apontar que no início do post do Graeme, ele faz questão de dizer: "A realidade deste benchmark é que ele é mais para Rails vs Groovy + SpringMVC + Hibernate + Sitemesh. O grails pode até receber algum crédito, mas o trabalho pesado é feito principalmente por Spring e Hibernate.".

Eu acho esse tipo de benchmark importante para acalmar os ânimos dos usuários do Grails que têm grande preocupação com performance. No fim das contas, estamos comparando uma solução que roda na plataforma Java, que utiliza alguns frameworks conhecidos (Spring, Hibernate, etc), com uma solução do Rails. E o resultado, por enquanto, fala por si só. Eu, particularmente, fico ainda mais confortável de seguir utilizando Grails nos meus novos projetos.

Em seguida ao post, a discussão na maillist continuou, e o assunto escalabilidade surgiu, como não poderia deixar de ser. Afinal, performance != escalabilidade.

Para uma aplicação Grails ganhar em escalabilidade, que no fundo é uma aplicação que roda na JVM, há sempre a possibilidade de se colocar esta aplicação sobre o Terracotta (que recentemente ficou open source lançando o Open Terracotta) ou então o Coherence.

Por outro lado, foi sugerida uma solução bem mais simples que pode dar conta da escalabilidade até um certo ponto. Basta colocar o Squid na frente do servidor, recebendo as requisições, e fazendo com que a aplicação Grails retorne corretamente os headers para o Squid. Se precisar de mais escalabilidade, pode-se aumentar o número servidores com Squid. Até um único servidor com Squid, Grails e Tomcat (ou Jetty, ou...) pode ser usado logo de início. Para resumir, esta solução usa o Squid como um Proxy Reverso de cache para fazer um cache do conteúdo de uma aplicação Grails. No fundo poderia ser uma aplicação Grails, PHP, Rails, ....

Por último, mas não menos importante, já que estamos falando de Grails, e consequentemente de Hibernate, um cache para o hibernate usando o EhCache pode também trazer grandes resultados.

Até a próxima...

[]s
Felipe

Aplicação pública feita em Grails com código fonte disponível

Parece que o ano realmente só começa depois do carnaval. Este mês de fevereiro foi bastante movimentado, e março também começou bem agitado. Já se passou mais de um mês desde meu último post. Prometo tentar colocar novos posts com mais frequência.

Algumas coisas que me chamaram a atenção nas últimas semanas foram:
1) Glen Smith criou o site groovyblogs.org . Ested site é uma aplicação feita em Grails, e foi feita como parte do projeto de "desafio 20h". Ele queria ver o que poderia produzir com Grails em 20h. Acabou fazendo este site legal que agrega blogs sobre groovy e grails. Parece brincadeira, mas em 20h ele produziu bastante funcionalidade se olharmos o que é preciso fazer para ter um site com estes requisitos no ar: autenticação, cadastro de usuários, busca do conteúdo dos blogs cadastrados através de seus feeds RSS, varredura da maillist do Grails, entre outros detalhes.

Mais uma vez é a prova do alta produtividade do Grails aliada ao poder de Java e seus projetos open-source. Por exemplo, para buscar os feeds nos diversos blogs cadastrados, ele usou o Apache Commons Http, o que facilitou bastante a vida dele.

Além disso tudo, o site tem seu próprio código fonte disponível, servindo de um belo exemplo de aplicação grails. Download do código aqui. Lá você verá tbem a possibilidade de download do Groogle, que é a solução que o Glen Smith deu para integrar uma aplicação Grails com um mecanismo de busca utilizando o Lucene.


Depois vou falar um pouco sobre outras coisas que vi por aí:


Tanta coisa pra falar....tão pouco tempo.


Abcs
Felipe

Versão 0.4 do Grails Liberada

Hoje, dia 31/01 a versão 0.4 foi liberada pela equipe de desenvolvimento do Grails. É uma versão muito importante por acertar diversos pequenos bugs, e por implementar novas funcionalidades importantes. Download aqui.

Uma delas é o suporte a Reloading para classes de Serviços, por exemplo. Além de outros artefatos que antes não se fazia reloading. Portanto, você pode desenvolver sem ter que fazer deploy novamente, sem dar stop no container web. Vai agilizar muito o desenvolvimento iterativo.

Outra é a novidade do Grails Plugins. Agora você pode criar plugins para ó Grails, e utilizar este seu plugin em outras aplicações Grails. Por exemplo, já implementaram o XFire plugin para quem quer utilizar o XFire para gerar Web Services na sua aplicação Grails. Fizeram também o Laszlo Plugin. Um outro usuário comentou que você pode, numa grande aplicação sendo desenvolvida, implementar os módulos desta aplicação como plugins do Grails. Assim, você pode fazer um deploy usando alguns módulos, e em outro caso, não usar determinados módulos. Muito intererssante. Vale conferir!

Algumas bibliotecas foram atualziadas, como Spring 2.0, Hibernate 3.2 e Groovy 1.0.

Grails está mais estável do que nunca. A versão 0.4 poderia facilmente ser chamada de 1.4 se os desenvolvedores se preocupassem um pouco mais com marketing. 0.4 não significa instável ou incompleta. Podem usar em produção!

Tudo que foi implementado pode ser visto aqui.

Aplicações públicas usando Grails que estão em produção são:
- Site da Pepsi Co, http://www.copellafruitjuices.co.uk/ .
- TV Voting: http://www.tvvoting.com/

[]s
Felipe

Mais envio de email: Autenticação SMTP, GroovyTemplates e integração com Spring

Escrevi um pequeno tutorial no wiki do Grails sobre como enviar emails com autenticação a um servidor Smtp. O conteúdo do email é Html, e é gerado dinamicamente com GroovyTemplates. O envio é feito pelas classes do Spring, e a configuração ficou de tal forma que possibilita, sem alterar nenhuma classe, o envio com autenticação, sem, para diferentes ambientes, etc.

Como tem muito mais código do que texto, não traduzi para o português.

Ficou interessante: veja aqui o tutorial.

[]s
Felipe

Geração de boletos com JBoleto e Grails

Um dos projetos que venho desenvolvendo atualmente, e o único usando Grails, tem me dado muitas agradáveis surpresas. Precisei implementar um busca no sistema: usei o Lucene, como descrevi aqui. Agora precisei gerar boletos bancários na mesma aplicação. Em 30 min implementei isso, usando o JBoleto. É muito bom usar Java pois a comunidade é extremamente criativa, produtiva e compartilha muita coisa em projetos open source.

O JBoleto é um pequeno projeto em java que ajuda na geração de boletos bancários. Por sorte, eu precisava gerar boletos do Banco do Brasil. O jboleto já está pronto para o Banco do Brasil. Bastou eu configurar para os dados da conta, e pronto, eu tinha boletos sendo gerados para os pedidos da loja virtual sendo desenvolvida neste projeto. Outros bancos também já têm suporte: Itáu, Bradesco, Sudameris, Santander. E do jeito que foi feito, você pode facilmente criar novos boletos para novos bancos usando o JBoleto.

Parabéns para a comunidade Java. É muito bom fazer parte dela.

E para não deixar de fazer meus elogios ao Grails, é muito bom poder usar os projetos open source em Java dentro de uma aplicação Grails. Fica tudo tão simples! :-)

[]s
Felipe

Grails eBook disponível

É muito importante, em qualquer projeto de framework open-source hoje dia, ter uma boa documentação e uma comunidade ativa e bem receptiva. A comunidade o Grails já tem, e a documentação está ganhando corpo.

Mais um livro foi plublicado, agora com versão eBook gratuita.
Veja aqui no infoQ. O livro é sonsiderado um Mini Book, e acompanha código fonte dos exemplos.

[]s
Felipe

Grails no mundo Corporativo?

Um leitor do meu blog me enviou um e-mail perguntando:
"Acha que este framework representa um ponto de virada na programação? Irá ser muito usado em empresas? Pra grandes projetos ... é aconselhavel?"

Estas perguntas são perigosas de serem respondidas, pois afinal são previsões do futuro, ou uma opinião pessoal baseada no sentimento ou no gosto de cada um. É sempre melhor ter fatos para podermos elaborar em cima dos mesmos.

Apesar disso, vou me arriscar e, ao invés de afirmar, vou apenas emitir minha opinião.

Resposta 1: Acho que o Grails conseguiu juntar duas características difícieis de serem unidas: simplicidade para o desenvolvedor, que é um ser humano que gosta de coisas simples (sempre tem as exceções, calro); e flexibilidade, poder e robustez tecnológica. Como o Grails é implementado em Groovy, a linguagem fornece muita simplicidade para o desenvolvedor, aumentando bastante a produtividade de codificação. Além de Groovy, sendo o Grails um framework MVC para web do jeito que foi feito, ele facilita muito a implementação de operações rotineiras no desenvolvimento web: operações CRUD, validação, uso de Ajax, e por aí vai. Então, o nível de abstração subiu bastante em relação a frameworks MVC integrados com soluções de persistência como o Hibernate. Desenvolver em Graisl comparado com SpringMVC + Hibernate, é muito mais simples (com Grails). MUITO MAIS SIMPLES! E com o MESMO poder!!! Pois usa SpringMVC + Hibernate por baixo dos panos.
Ok, ok. E a resposta? Vamos lá.....Acho que sim: acredito que os desenvolvedores irão perceber as vantagens que o Grails oferece em relação a Struts, WebWork, SpringMVC da mesma forma que percebram as vanagens do uso do Struts em relação aos frameworks caseiros. O Struts foi um marco no desenvolvimento web em Java. Acho que o Grails será um marco no desenvolvimento web na plataforma Java. Com certeza!

Resposta 2: As empresas, principalmente as grandes e as médias, vêm investindo muito há anos na capacitação de suas equipes. Ainda hoje, se vê muitos anúncios de oportunidades para desenvolvedores com experiência em Struts. Mas porque Struts? Será que Struts é o que há de melhor hoje em dia no que diz respeito a frameworks MVC para web em java? Uns podem dizer que sim. Para mim, não. E olha que já usei muito o Struts, e ainda uso (infelizmente). Ele não é o melhor atualmente, mas possui uma base de desenvolvedores que o conhecem muito grande. Possui uma comunidade ativa enorme. Possui livros e livros publicados, cursos sendo vendidos, equipes inteiras com seu conhecimento. E aí? Vai tudo pro lixo porque Grails surgiu? Certamente que não. Porém, as empresas que estiverem dispostas a experimentar novas tecnologias ou frameworks estarão dispostas a investir em determinado caminho. Como tal, poderão ter um retorno alto ou não. É um risco que se corre. Tem gente que ganha muito dinheiro na bolsa de valores, mas é arriscado. Aqueles que partirem para o uso do Grails, na minha opinião, terão uma vantagem competitiva, pois se preocuparão menos com detalhes de baixo nível das APIs de Java, e terão mais tempo para pensar na solução de negócios dos seus clientes. Isso pois, a produtividade com Grails é MUITO maior que com os demais frameworks MVC para web em java. Respondendo então: acho que sim, mas isso levará tempo. Aos que forem pioneiros, os resultados dirão.

Resposta 3: grandes projetos? O que são grandes projetos? Se forem projetos que usam persistência, log, web services, tarefas agendadas, geram relatórios, busca textual indexada, etc, etc. A resposta é sim. Se para estes projetos você usa Java com Struts ou WebWork ou SpringMVC, Hibernate ou iBatis, Log4j, Quartz, Acegi, JasperReports, XFire ou Axis, Lucene ou Compass... Se você usa isso tudo, porque não usar Grails? Afinal você pode continuar usando isso tudo, mas de uma maneira MUITO MAIS SIMPLES. Se projetos grandes são projetos com um número de usuários muito grande, e se para estes projetos você usa um sistema web em Java. Porque não usar Grails? Afinal, no final das contas, tudo é bytecode sendo executado pela JVM. Então você pode continuar usando seu servidor de aplicações java que você já usa. Pode continuar fazendo o balanceamento de carga que você já faz. O que muda é o nível de abstração em tempo de desenvolvimento.

Minhas opiniões foram influenciadas por este post.

Um abraço e até a próxima.