Grails + GWT = Rock n Roll: Parte 1 - Desbravando um novo mundo

Meus amigos leitores (quantos devem ser estes leitores? deixe uma mensagem dizendo que vc é meu leitor! rs...) ... Bem vindos ao maravilhoso mundo do Rock n Roll. As bandas de rock muitas vezes são mal vistas por pessoas mais tradicionais. Outras vezes são veneradas por jovens rebeldes. Não importa. As boas bandas no final das contas só fazem uma coisa: dão um show de Rock n Roll. Mas o que é isso afinal? Sem dúvida a música é o principal produto desta fábrica rebelde. Por trás de pessoas tatuadas, cheias de brincos e roupa rasgada, por vezes alcoólatras e drogadas, bem no fundo há músicos que juntos ( e aqui está o mais importante: JUNTOS) conseguem tocar almas sedentas de Rock puro e simples. Já ouviu um bom Lynyrd Skynyrd com suas 3 guitarras, piano, batera, etc? É brincadeira o que esses caras tinham de musicalidade. Juntos eles deixam os fãs de rock embasbacados até hoje em dia.

Depois desta introdução metafórica, vou iniciar hoje uma série de posts a respeito de GWT e Grails, duas tecnologias que juntas, para mim, estão despontando como a maior banda de Rock dos últimos tempos.

Sobre o Grails todos sabem que eu acho que é simplesmente o melhor framework para desenvolvimento web na plataforma java (pelo menos daqueles que eu conheço).

Sobre o GWT (Google Web Toolkit), eu sou um mero iniciante, ou melhor, curioso. Para ser sincero, tenho ficado um pouco cansado de lidar diretamente com HTML, CSS e Javascript, principalmente com a montanha de Javascript que se lida ao desenvolver aplicações AJAX. Mesmo usando bibliotecas como jQuery, ou Prototype, mesmo assim, é muito Javascript para se lidar.

Por conta disso (e outros motivos), acho que o GWT pode ser de grande ajuda, de grande ajuda MESMO. Um dos grandes motivos também é a crença que eu estou ficando de que o GWT pode ajudar muito a se ter uma arquitetura decente também na camada View, e não apenas no model, no controller, na DAO, etc. Se formos olhando uma arquitetura de uma aplicação Grails tradicional de baixo para cima, podemos ver que:

• - a DAO está bem resolvida,
• - os Serviços estão lá e cumprem seu papel (de controle transacional, por exemplo),
• - os Controllers também tem seu papel de fronteira entre o mundo HTTP e nossas regras de negócio,
• - mas aí chega na View e facilmente a gente começa a se perder e fazer uma bagunça com HTMLs, CSSs, Styles, Javascript em arquivos .js, Javascript inline, e por aí vai.

Andei estudando um pouco de GWT para entender mais a fundo e estou começando a acreditar que ele pode ser usado para, mais facilmente, arquitetar decentemente a camada View. Por exemplo, pode-se usar um MVP (Model View Presenter) com o GWT. Alguém aí pode dizer que pode-se fazer isso também com o Javascript diretamente. Sim, até pode, mas que o GWT facilita as coisas, ah facilita. Primeiro: É JAVA! Você ganha ferramentas, refactorings, debugging, e muito mais. Ganha também o fato de que o GWT abstrai você de preocupações mundanas, como por exemplo a ofuscação e minimização do Javascript. Ele faz isso pra gente.

Então é isso galera. Vamos começar.... Vou escrever os posts de acordo com a aventura que eu mesmo estou passando. Nunca desenvolvi uma aplicação real com GWT + Grails. Então vamos desenvolver uma juntos. Será pequena, mas vamos nessa!

Entendendo o GWT

Para começar eu instalei o plugin do GWT para Eclipse. Baixei também o SDK do GWT (neste momento estou usando a versão 2.0.3 do GWT). A página que uso para download de tudo é essa: http://code.google.com/intl/en/webtoolkit/download.html

Fiz uma pequena experiência com o GWT sozinho, sem o Grails ainda. Para isso, pelo Eclipse eu criei um projeto GWT novo, usando os wizards que o plugin me dá. Ele cria um projeto já sendo executado de dentro do eclipse, tudo bonito. E esse novo projeto já tem uma pequena página de exemplo, com um diálogo modal, uma requisição Ajax e tudo mais. Tudo para você começar a entender o tal do EntryPoint, entender os Modules, os Widgets e tudo mais.

Portanto, a primeira sugestão que eu dou é essa: brincar com a aplicação nova gerada pelo plugin do Eclipse.

A primeira coisa que percebi com aplicações GWT é que tudo é AJAX. Toda a comunicação com o servidor é assíncrona. Aí, vi que a aplicação gerada pelo plugin do Eclipse tem um "layout" diferente da aplicação Grails. Então surgiu o primeiro problema: como juntar os dois mundos?

Bom, em último caso, o GWT no fundo só serve para gerar os HTMLs e Javascript. Então você pode compilar seu projeto GWT, pegar o HTML e Javascript gerado, e copiar para seu projeto Grails para a parte de web-app. Simples assim! Mas isso não seria nada produtivo.

Aí me veio a dúvida: como que as pessoas por aí juntam o Grails com o GWT? Elas fazem um projeto GWT e outro Grails, e depois juntam de alguma forma (com maven por exemplo)? Ou vai tudo num projeto só?

E mais: se forem dois projetos distintos, como lidar com a Same Origin Policy (SOP)?

E vi que realmente tem gente que usa a primeira forma, e gente que usa a segunda. E tudo gente de respeito por aí. Por exemplo, eu gosto muito o Matt Raible. Desde meus tempos de AppFuse eu sou fã dele. Aprendi muito com a estrutura que ele montou para o AppFuse.

E não é que o Matt Raible usa a primeira forma? Ele tem dois projetos, um GWT e outro Grails. Aí, em desenvolvimento ele deixa assim mesmo, como duas aplicações web rodando simultaneamente. E simplesmente lida com a SOP através de um Proxy espertinho na aplicação GWT. Este proxy recebe as requisições no servidor do cliente GWT, repassa para a aplicação Grails, recebe de volta a resposta desta, e repassa a mesma para o browser que tem o cliente GWT. Muito doido, mas funciona.

E em produção ele na verdade junta tudo. Ele tem lá um Maven bem esperto que faz tudo isso pra ele automaticamente, gerando um único WAR que tem a aplicação Grails e o cliente GWT. Aí simplesmente o problema do SOP desaparece.

A outra alternativa é juntar tudo desde o início numa única aplicação. Para facilitar esta tarefa, um tal de Peter Ledbrook fez o GWT Plugin para Grails (não se deixe enganar por esta página. O plugin já está na versão 0.5 e suporta GWT 2.0).

Eu, por enquanto, vou seguir este caminho mais simples (sempre gosto da simplicidade): vou usar o GWT Plugin para Grails. Parece tão simples agora......mas eu fiquei umas duas semanas até chegar a esta conclusão. E até agora queria entender porque o Matt Raible não usa o plugin. Talvez ele seja ruim por algum motivo. Se for isso, eu ainda não descobri.

Então amigo, aí vão os passos iniciais:

• - Instalar o SDK do GWT
• - Criar a variável de ambiente GWT_HOME apontando para a raiz do SDK do GWT
• - Instalar o Plugin de Eclipse do GWT
• - Criar uma aplicação pura e simples GWT usando o plugin do eclipse.
• - Abrir a aplicação no browser usando a URL apresentada pelo Eclipse (com o parâmetro gwt.codesrv na URL - este parâmetro é que permite você alterar o código Java e imediatamente dar um refresh no browser e ver sua mudança lá).
• - Garantir que o browser instalou o plugin de execução do GWT.
• - Executar esta aplicação e brincar um pouco com os diferentes Layouts de GWT.

Pronto. Agora que você brincou o GWT um pouco, vamos juntar os dois ( GWT + Grails ):

• - Criar uma nova aplicação Grails com o comando grails create-app rockgwt
• - Vai pra dentro dela ( cd rockgwt )
• - Instalar o plugin GWT do Grails (usando o comando grails install-plugin gwt ). Eu estou usando o grails 1.2.x e o plugin 0.5
• - Criar um GWT Module com o comando do plugin grails create-gwt-module com.rockgwt.RockNRoll
• - Criar a página principal do GWT para o seu Module. Eu fiz isso criando um controller do grails e uma Page index.gsp para este controller. Esta page é que irá hospedar o GWT:
• 1) grails create-controller com.rockgwt.controller.Principal
• 2) grails create-gwt-page principal/index.gsp com.rockgwt.RockNRoll (quando este comando te perguntar se você quer criar o Controller, diga que não, pois você acabou de criá-lo no passo anterior --- acho que o plugin não reconhece o Controller criado com package, sei lá).
• - Compilar o seu módulo com o comando grails compile-gwt-modules (demora um pouquinho mesmo)
• - Executar o Development Mode com o comando grails run-gwt-client Perceba que vai se abrir a janela da aplicação Development Mode do GWT
• - Abra outro Terminal , vá para o seu projeto rockgwt e execute a aplicação grails (é isso mesmo, você terá duas coisas rodando: o grails run-app da aplicação, e o grails run-gwt-client anterior, do GWT).
• - Abra o browser e vá para a Home da sua aplicação GWT + Grails em: http://localhost:8080/rockgwt?gwt.codesvr=127.0.0.1:9997
• - Na verdade, pode ser que na sua máquina a porta final seja outra, não sei. Para ganrantir sucesso, basta clicar no botão Launch Default Browser existente na janela do Development Mode.
• - O endereço que você quer acessar no final de tudo será o seu controler Principal, ou seja:
  http://localhost:8080/rockgwt/principal/index?gwt.codesvr=127.0.0.1:9997
• - Não deixe de colocar este parâmetro maluco. Ele é o responsável por permitir que você altere o código Java e dê um refresh no browser para ver as modificações imediatamente.

Agora, abra a sua classe RockNRoll e deixe ela assim:

(esta classe se encontra no seu projeto rockgwt em src/gwt/com/rockgwt/client)

package com.rockgwt.client;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.RootPanel;

/**
* Entry point classes define <code>onModuleLoad()</code>.
*/
public class RockNRoll implements EntryPoint {
/**
 * This is the entry point method.
 */
public void onModuleLoad() {

    final Button sendButton = new Button("Rock n Roll");

    RootPanel.get().add(sendButton);
}
}

Pronto. Dê um refresh no seu browser, e o botão "Rock n Roll" estará lá.

UPDATE (8/3/2010):
- Apenas para completar, para poder usra o Eclipse com tudo redondo, clique no botao direito do mouse em cima de src/gwt e selecione a opção Build Path > Use As Source Folder
- E por último clique com o direito do mouse em cima do projeto rockgwt e selecione a opção Google > Webtoolkit Settings, lá dentro do wizard que se abre, selecione o primeiro checkbox que aprece lá em cima "Use Google Web Toolkit". Assim você terá tudo que precisa no classpath da aplicação no Eclipse.

Até a Parte 2 desta série... Aguardo Comentários para saber se estou agradando com este tema. Abcs

Executando códigos diferentes em Desenvolvimento e Produção

Há vezes em que queremos executar códigos diferentes dependendo do ambiente que a aplicação está sendo executada. Por exemplo, integrações com sistemas externos algumas vezes são simuladas em Desenvolvimento, e são executadas pra valer em Produção.

Aí vai uma maneira simples de executar uma coisa em Desenvolvimento e outra em Produção (ou para quantos ambientes você tiver...).

import grails.util.Environment;

class MeuController{
   Environment.executeForCurrentEnvironment {
       production {
           // AQUI vai o código que deve ser executado em produção
       }
       development {
           // AQUI vai o código a ser executado em desenvolvimento.
       }
   }
}

Boas informações sobre grails em português

Pessoal

para quem ainda não conhece, foi lançado o Grailsbrasil Blogs que é um agregador de blogs em português sobre o Grails. Lá você poderá ver diversos posts de diversas pessoas que escrevem sobre Grails e afins. Vale conhecer.

Abcs

Felipe

Grails e datas: Bind automático de atributo do tipo Date com formato customizado

Segue uma pequena receita de bolo para quem não está usando o datePicker padrão do Grails.

O Grails vem com uma tag que é a g:datePicker.

Ela serve para gerar listboxes (comboboxes) de dia, mês, ano, hora, minuto e segundo. Você pode até escolher quais desses comboboxes você quer que apareçam.

Mas há vezes que não queremos usar estes combos, e simplesmente queremos um campo texto onde o usuário pode digitar a data num formato qualquer, como por exemplo, dd/MM/yyyy, ou dd/MM/yy, ou yyyyMMdd, ou...ou...ou...

E ainda, se você tiver uma aplicação com internacionalização, aí pode ser que para usuários com Locale em português, o formato de entrada deste texto de data é dd/MM/yyyy , porém, se for em inglês, aí é MM/dd/yyyy.

Bom, o objetivo aqui é mostrar como dizer para o Grails para usar este formato de entrada de datas para que ele faça o parse automaticamente toda vez que encontrar um atributo do tipo Date em um objeto de domínio (ou um objeto Command) que ele precisa fazer o bind dos parâmetros recebidos num POST (ou GET).

Então:

1) O usuário preenche um campo input type="text", com uma data num formato que você determina, ex: MM/dd/yyyy

2) Ele envia este POST, que chega no seu Controller disponível no atributo params

3) você quer fazer o bind automático usando (digamos que meu objeto de domínio seja Pessoa, e nele haja um atributo Date dtAniversario):

Pessoa tx = new Pessoa(params)

Para isso acontecer de forma correta, e o seu atributo dtAniversario estar preenchido corretamente com um valor do tipo Date, é preciso criar um PropertyEditorRegistrar customizado para você. Crie um pacote em src/groovy , digamos com.meusistema.editor , e crie lá o seu PropertyEditorRegistrar:

package com.meusistema.editor;

import java.text.SimpleDateFormat;
import java.util.Date;

import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
import org.springframework.beans.propertyeditors.CustomDateEditor;
import org.springframework.context.i18n.LocaleContextHolder;

public class CustomPropertyEditorRegistrar implements PropertyEditorRegistrar {

  def messageSource;

  public void registerCustomEditors(PropertyEditorRegistry registry) {
    registry.registerCustomEditor(Date.class, new CustomDateEditor(new SimpleDateFormat(messageSource.getMessage("dateFormat4y",null,'dd/MM/yyyy',LocaleContextHolder.locale )),true));
  }

}

Perceba que para funcionar corretamente, você precisa editar os seus grails-app/i18n/messages.properties (messages_en_US.properties, messages_pt_BR.properties) para que tenham cada uma a sua configuração correta. Ex para o pt_BR:

dateFormat4y=dd/MM/yyyy

O passo seguinte é registrar este PropertyEditorRegistrar no arquivo grails-app/conf/spring/resources.groovy:

beans = {

  customPropertyEditorRegistrar(com.manubia.propertyeditor.CustomPropertyEditorRegistrar) {
     messageSource = ref('messageSource')
  }

}

Pronto. É isso!

Abcs a todos

Como iniciar com Scrum - Bate papo com um futuro Scrum Master

Oi pessoal,

eu comecei a orientar uma pequena empresa parceira em como iniciar a implantação do Scrum. Abaixo reproduzo meu e-mail para o membro da equipe q será o Scrum Master. Comentários? Aguardo contribuições....tenho muito interesse em conhecer diferentes realidades....

Um abraço

--------------------

Minhas sugestões:

1) Você deve ser o Scrum Master da equipe

2) Estudar um pouco de scrum para entender o linguajar, e os conceitos.

a) o que é e qual é o papel do Scrum Master ( http://blog.eof.com.br/2008/03/06/qual-e-o-papel-do-scrum-master/ )

b) entender os principais conceitos: Product Backlog, Sprint Backlog. Sprint Planning Meeting, Sprint Review, Planning Pocker

( http://laguiar.wordpress.com/2008/06/30/introducao-scrum/ )

3) Criar o Product Backlog. Para isso, você deve interagir com o cliente. Ele é o Product Owner, e é ele quem sabe como gerar o Product Backlog, e é ele quem sabe priorizar este backlog. Sugiro, se necessário, criar um product backlog para cada produto do projeto ( Admin, Carrinho de Compras, Barramento SOA, etc).

4) Criar um release Backlog para o release 1. Definir releases, junto com o cliente. Pegue o Product Backlog e quebre ele em dois ou três releases. Esses passos 3 e 4 são trabalhosos, e depende do seu esforço e do esforço do cliente. Você provavelmente vai ter umas 3 reuniões DE TRABALHO com ele, cada uma de umas 4 horas de trabalho. Diga a ele que é isso que você quer, que a empresa precisa: de uns 3 dias, de 4 hs, de trabalho conjunto seu e dele para gerar Product Backlogs e Releases Backlogs.

5) Crie um conjunto de cartas de baralho para cada integrante da equipe. Cada um tem que ter um jogo completo dessas cartas. Sugiro comprar uma cartolina mais grossa e fazer as cartas. Tipo isso aqui: http://www.flickr.com/photos/tlaukkanen/488795952/sizes/m/ ...... os números das cartas são esses mesmos: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, e ?.

6) Junte toda a equipe e, juntos, façam um Planning Pocker, usando as cartas. Estimem cada item do backlog do Release 1. Como funciona este pocker:

- coloca-se no meio da mesa o item de backlog (ou fala-se o item).

- quem tiver dúvidas a respeito do item, pergunta, e as duvidas devem ser tiradas ali na hora. Todos devem entender o item de backlog.

- cada desenvolvedor escolhe uma carta. A carta representa os pontos de dificuldade de implementar o item de backlog. Um item muito facil de fazer é a carta 2. Um item dificílimo é a carta 40. As cartas menores que 2 e maior que 40 são para as exceções. Um item já feito recebe a carta ZERO.

- Após todos escolherem suas cartas, sem mostrar aos demais, todos juntos abrem suas cartas.

- Geralmente tem uma pessoa que escolhe uma carta de menor valor, e um outro que escolhe uma carta de valor mais alto. Por exemplo, um escolhe a carta 5 e outr escolhe a carta 20.

- O que escolheu o menor valor deve justificar porque escolheu um valor tao baixo. O que escolheu o maior valor deve fazer o mesmo: justificar.

- Após as justificativas, todos recolhem suas cartas e escolhem novamente outra carta (ou a mesma).

- Todos abrem suas novas cartas. Desta vez deve haver um consenso maior entre os participantes.

- Determine, finalmente, o valor de pontos deste item de backlog. O consenso é que determina. Se 4 escolheram a carta 13 e 1 escolheu a carta 20, 13 é o vencedor.

- E assim vai para todos os itens do backlog da Release 1. Faça na ordem de prioridade do backlog.

7) Marque um Sprint Meeting. Uma reunião com todos da equipe, você e o Product Owner (cliente).

a) a reunião é de 4hs de duração. Não mais do que isso. Se ela começar a passar de 4hs, interrompa a reunião. Uma das características do Scrum é o conceito de janela de tempo. O tempo é fixo. O que der pra fazer é feito, o que não der, não deu. Tanto para as reuniões, quanto para o tempo do Sprint (2 semanas).

b) O cliente pode repriorizar os itens do backlog, pois esses agora já estão estimados, e o cliente pode mudar a prioridade. O cliente deve determinar a ordem de prioridade dos itens deste backlog.

c) Nesta reunião apresenta-se a lista de itens do Release 1 Backlog para todos. Caso haja alguma dúvida por parte dos desenvolvedores, este é o momento de perguntar as dúvidas ao Owner. Pode-se até mudar as estimativas de pontos do item devido ao melhor entendimento do item. É importante a equipe perguntar TUDO: testes de aceitação, comportamento de tela, requisitos técnicos, etc). Você como Scrum Master tem o papel de provocar a equipe para perguntar e ter certeza de que a equipe está entendendo.

d) A partir desses, que já estão priorizados, a EQUIPE escolhe os itens que conseguirá se comprometer para a entrega ao final do Sprint. Quem diz o quanto consegue entregar é a equipe. Neste momento a equipe está se comprometendo a entregar aqueles itens de backlog. Com isso, criou-se o Sprint Backlog. A equipe deve considerar a completude da entrega: implementação, testes, documentação.

e) Pronto. Aqui então a equipe tem o Sprint Backlog. São os items que serão desenvolvidos no Sprint que se inicia.

f) Outro ponto importate é você, Scrum Master, não permitir que o cliente induza a equipe a aceitar mais itens do que conseguiria.

g) E finalmente: o Product Owner tem que se comprometer a não alterar o Sprint Backlog durante o sprint. Nessas 2 semanas que se iniciam, o Sprint Backlog NÃO muda.

8) Iniciar o Sprint de 2 semanas. Durante este período, seria bom a visita do Product Owner (cliente) regularmente. De 3 em 3 dias, ou algo assim. Desta forma a equipe tem a oportunidade de tirar dúvidas.

9) O Sprint se inicia com uma reunião da EQUIPE, sem cliente. Nesta reunião, o objetivo é quebrar cada item de backlog em Tarefas técnicas:

a) Modelagem

b) Criação de scripts de Banco de Dados

c) Implementação de Regras de Negócio

d) Estudo e avaliação de tecnologia

e) Implementação de testes unitários

f) Implementação de testes de integração

g) documentação

h) Implementação de Telas (html, css, javascript)

etc

- Cada item do Sprint Backlog deve ser quebrado em Tarefas.

- esta reunião pode ser logo em seguida da reunião de Sprint Planning Meeting que ocorreu com o Owner. Pode marcar o Meeting de manhã, e a reunião da equipe para quebrar em tarefas a tarde.

10) Primeiro dia do Sprint:

a) Você, Scrum Master, promove o Daily Meeting, que é a reunião diária de 15 min, em pé! Tem que ser rápida. Aqui, cada um diz o que fez ontem, os problemas que está enfrentando, e o que fará hoje (ou amanhã). A própria equipe se organiza em dizer quem fará quais tarefas. Sempre em ordem de prioridade dos itens do backlog.

11) Você, Scrum Master, deve deixar visível o Burn Down Chart. Desenhe ele no quadro para todos verem. Atualize diariamente, assim todos acompanharão o andamento do Sprint. Veja um exemplo aqui http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls

- Neste gráfico, a barra representa o total de pontos que ainda faltam no Sprint.

- É importante diferenciar entre os pontos planejados do Sprint (que foram escolhidos pela equipe para formar o Sprint backlog), e os pontos que surgiram ao longo do Sprint. Coisas imprevistas que apareceram e tiveram que ser feitas. Essas, devem entrar como tarefas extras, e devem ficar evidente, para que o cliente entenda qualquer atraso ou não entrega do que foi acordado.

12) Diariamente faça o Daily meeting, com todos da equipe, em pé. 15 min. Se houver algum problema, algum impedimento, que esteja causando paralisia da equipe, você como Scrum Master deve solucionar isso.

13) Durante o Sprint de duas semanas, você poderia atuar como um projetista de Protótipo de Telas. Sente com o cliente, entenda os itens do backlog do Release 1 que não fazem parte do Sprint 1 (ou seja, vc estará planejando o sprint seguinte, enquanto a equipe trabalha no sprint atual). Você poderia ir criando protótipo de telas que seriam aceitos pelo cliente, e direcionariam o desenvolvimento da equipe. Power point é uma ferramenta simples e eficiente para isso. Mando um exemplo em anexo.

O que todos deveriam saber sobre Mysql

Nestes tempos de desenvolvimento com frameworks que tentam (e conseguem) facilitar muito nossa vida abstraindo detalhes de baixo nível, muitas vezes deixamos de nos preocupar com o que se passa lá por baixo.

Mas, em aplicações que tendem a crescer, que com o tempo vão deteriorando em performance, muitas vezes os problemas estão no banco de dados, na forma como acessamos o banco, em como construímos nossas queries...

Esta apresentação aqui, apresentada no Sun Tech Days 2009, é muito boa para quem usa Mysql.

http://developers.sun.com/events/techdays/presentations/2009/pdfs/TD_SP_MySQL_Karlsson.pdf

Abcs

Grails e Cloud: desenvolvimento, deploy, execução e monitoramento. Ciclo completo com Grails na Nuvem.

No início havia muitas dúvidas se o Grails iria ser útil para aplicações grandes, ou de grande porte. Mas peraí, o que é uma aplicação grande? eBay é gigante. Se considerarmos uma medida, aí acho que podemos definir grande. Page-views por mês, por exemplo, pode ser uma medida, já que é fácil de saber, de monitorar, etc.

Um eBay tem algo em torno de 15 bilhões de page-views por mês. A globo.com tem uns 2 bilhões de page-views/mês. Um Peladeiro.com.br tem 1,2 milhão de page-views/mês. O Peladeiro é pequeno, Globo.com é grande, eBay é gigante. Pelo menos na minha opinião, sem muito exercício científico.

Além da medida de grande número de acessos, há também: grande volume de dados, necessidade de alta disponibilidade e redundância, escalabilidade, hot swap, cluster failover, etc, etc....

Aí voltamos a pergunta original: o Grails é bom para isso? Dá pra confiar que uma aplicação grails serve para uma demanda de uma aplicação de grande porte?

Alguns casos reais confirmam que a resposta é sim. Por exemplo, o Linkedin.com usa Grails para algumas partes. Este site tem as seguintes características: 22 milhões de membros, 1,2 milhão de novos membros por mês. Acho que o site mesmo, quando vc acessa linkedin.com, não é em grails, apesar de ser em java. Mas há partes feitas em Grails.

Onde eu quero chegar afinal? Meu ponto é que acho que atualmente o Grails chegou aonde queríamos que ele chegasse: está maduro o suficiente, estável, performance boa o suficiente, há ferramentas para desenvolvimento, e agora há serviços prestados por fornecedores que dão suporte ao deploy, execução e monitoramento de uma aplicação grails na Nuvem (Cloud).

Um grande player neste mundo de Cloud é a Amazon, com seu AWS . Mas como desenvolver uma aplicação Grails para rodar neste ambiente virtual? A nuvem está lá, mas você não vê. Tem solução poder computacional escalável, solução de storage, de banco de dados relacional na nuvem, e muito mais....

Mas como usar isso tudo? Como fazer uma aplicação Grails rodar nesta infra poderosa, mas complexa?

Aí que eu acho que a SpringSource está dando um show! Primeiro os caras inventam o Spring, que é solução para DESENVOLVIMENTO. Depois começam a expandir para servidores, que é solução para EXECUÇÃO. Depois fornecem solução para ferramentas ajudando mais ainda no quesito DESENVOLVIMENTO. Aí lançam produtos para gerenciar e monitorar (MONITORAMENTO). Por último, lançam um serviço que te ajuda executar aplicações java na infra de Cloud da Amazon: Cloud Foundry.

E por último, os caras compraram a G2One, que era a empresa responsável por Groovy e Grails. O resultado é: Grails tá pronto para rodar em tudo isso citado aí em cima.

Portanto, no momento presente, você pode desenvolver uma aplicação Grails usando tudo que este excelente framework oferece, pode usar os plugins de eclipse para Groovy e Grails que a SpringSource está desenvolvendo, pode fazer deploy, execução e monitoramento da applicação na nuvem da Amazon usando o CloudFoundry (ou o Cloud Foundry Plugin pra grails). Isso é excelente!!! Sua aplicação grails fica escalável, podendo usar instâncias com balanceamento de carga (load-balance) em diferentes zonas de disponibilidade, pode usar replicação master-slave para seu Mysql, pode usar SSL no apache, monitoramento e restart automático de servidores que falham, auto-escala de instâncias do EC2 da Amazon (pagando apenas pelo o que usa), pode usar backup automático de dados com snapshots.......... tudo isso para uma aplicação grails rodando na nuvem, e você gerenciando via Web.

Na teoria é lindo. Temos que ver na prática agora.

t+