PlayFramework Review

Posted on 14 March 2010

A pouco tempo fiquei conhecendo um novo framework para Java de alta produtividade, trata-se do PlayFramework http://www.playframework.org. A sua primeira versão estável foi disponibilizada em Fevereiro de 2008, e hoje se encontra na versão 1.0.1. Achei o framework interessante e resolvi escrever esse review.

Para testar o framework, fiz o tutorial do site que mostra como construir um blog. Foi bastante tranquilo, não deu erros inesperados e o tutorial estava bastante condizente com a construção da aplicação. Utilizei o eclipse para construir o projeto. O play vem com uma ferramenta que permite adaptar o projeto a várias IDEs de forma bem fácil.
A primeira coisa a se notar é que o play é um framework Java. Mas não é um framework JEE. Eu não vejo problema nisso a principio, mas ao invés de manter só o framework, o desenvolvedor do play, terá que manter também, uma arquitetura, um servidor, etc. Ainda não sei o que ele usa por baixo dos panos, mas seria bem viavel se utilizasse algo como um Tomcat turbinado.
Eu acho que o JEE hoje, com a utilização de frameworks não tem tanta importância na arquitetura da aplicação, a não ser para criar um request e response, e fazer a comunicação HTTP. No caso do JSF, por exemplo, request e response praticamente nem existem. O JEE, mesmo com as últimas versões, não oferece grande vantagem já que voce usará um framework por cima. Até mesmo o JSP está saindo de linha. E isso se deve ao fato de suas limitações. O pessoal acaba deixando de lado os recursos do JEE e criando o próprio engine.
Um outro aspecto, que faz grande parte das mágicas, que permitem ao play ser bastante produtivo é a utilização de um Java Agent. Esse java agent, apesar de eu não ter estudado a fundo, deve "tunar" as suas classes em tempo de execução. Fazendo os getters e setters que você não escreveu, implementando os métodos do Model e fazendo o Hot Deploy do seu projeto sem a necessidade de reiniciar o servidor. Um Class Loader especial provavelmente ajuda nesse processo também.
Hoje a maioria dos frameworks utilizam a manipulação de byte codes para facilitar o desenvolvimento. Essa manipulação permite que sejam feitas algumas coisas pelo usuário, que, na verdade, é a tarefa do framework. Antes da proliferação dessa técnica o que acontecia, é que o framework elevava a aplicação a um nível de abstração bem mais alto para poder trabalhar numa cama intermediária entre a JVM e a aplicação. Hoje os frameworks atuam entre o bytecode e a JVM, mantendo a camada de aplicação sobre o Java puro, ao invés de sobre uma camada do framework. Isso facilita bem o desenvolvimento e o aprendizado das ferramentas.
O esquema de redirecionamento também é bastante interessante. Quando você faz por exemplo:

GET     /posts/{id}                             Application.show 

O framework permite que acesse um post com a URL /posts/6, utilizando conceitos RestFull. Mas vai além disso, se você utilizar no seu código um redirecionamento como:

@{Application.show(post.id)} 

O framework irá ver que Application.show tem um route, e vai renderizar o link como /posts/${post.id}. Ou seja, faz a leitura ao contrário também. Isso eu achei bem legal.
A configuração do framework é através de arquivos de properties, que por sinal são bem completos. Esses arquivos são documentados e você quase não tem que escrever neles, já vem tudo pronto praticamente. Se quiser alguma configuração ou funcionalidade apenas descomente alguma linha do arquivo.
A linguagem utilizada nos templates tem bastante poder, e utiliza groovy para fazer o evaluation. Oferece uma sintaxe especial para diversos tipos de funcionalidade: # para chamar scripts ou tags, @ para links, etc. Isso torna a leitura do código fácil depois que voce acostuma com os símbolos. O sistema de includes das páginas também é legal, pois permite que sejam utilizados templates dentro de templates.
Os controllers são bastante simples de se escrever, sem segredo. E oferece um esquema de validação e mensagens, igualmente simples.
O framework tem uma característica de ser Stateless. Ou seja, você não deve guardar estado nos objetos. É uma arquitetura válida, não é necessário voce ter milhoes de objetos cada um num escopo diferente para ter uma aplicação robusta e bem implementada. Essa variedade de escopos usadas em alguns frameworks, acaba inclusive causando alguns problemas.
Uma outra feature que estudarei mais profundamente e me interessou, é que a sessão é gravada em cookies. Isso pode ser uma grande vantagem do framework. Já que não é utilizada memória do servidor, a aplicação pode escalar melhor.
A ferramenta parece ser bastante estável. Não apresentou erros durante o desenvolvimento. O tutorial é bem explicado, e tem boa documentação.
Vamos dizer assim que é um framework bem redondo.

Algumas críticas:
Natureza static: Apesar de concordar com a natureza stateless, não concordo muito com a natureza static. Nos controllers os métodos são todos static e parece que a ideia é trabalhar assim no framework, acho que é uma desvantagem bem grande, e deve ser revisto.
View: A linguagem utilizada em templates é bastante poderosa, mas as views são escritas praticamente com HTML. E as tags também são assim. É como se voce tivesse tag files do JSP, mas não tenha tags mesmo, escritas em Java.
Sobrescreve o JEE: O play é tudo: framework, servidor, ferramenta. Isso vai tornar mais complicada a adoção e também a evolução do mesmo, já que tem muito código a ser visto. O pacote do play tem 45 Mb. É muita coisa, é claro que por baixo dos panos foram utilizadas outras ferramentas. Mas como a integração é feita pelo play, esse código tem que ser mantido por ele.

Considerações finais:
O Play parece funcionar realmente, foi bastante estável nos testes feitos. O sistema de deploy é excelente. É produtivo e fácil. Apesar de ter todas essas vantagens, e que ele está seguindo a tendência, praticamente todo o framework pode ser substituído por ferramentas que existem no mercado. A grande vantagem do play é que já vem tudo pronto e configurado.
Para ter um framework igual ao play, você pode utilizar por exemplo o Spring. No controller utiliza algo como VRaptor ou Next, que são baseados no Spring MVC. Orientação a aspectos, para fazer os métodos que não são implementados por você como os getters, setters e métodos do Model. E utilizar um template mais poderoso do que o JSP. As queries já são contruidas com JPA mesmo. Aí você já tem um play. Com alguma configuração de class loader e java agent, você consegue o mesmo deploy. A diferença é que nesse caso você estará no Standard, ou seja, usando tomcat, eclipse, plugins, tudo que todo mundo já utiliza. Ao invés de jogar tudo fora e começar do zero.
Não estou criticando o framework e falando que ele é ruim por causa disso. Pelo contrário, acho que ele fez tudo certo, utilizando tendencias de mercado e tudo mais. Só que você começa de uma plataforma nova e isso dificulta bastante a adoção.
Apesar tudo que tem no play, existir no mercado, existe uma grande vantagem do play. Ele já está todo configurado e funcionando, as interfaces já foram testadas e estão estáveis. E não é fácil montar uma arquitetura dessa, gasta muito tempo, testes e código. E não é qualquer programador que consiga fazer isso.
A minha crítica em relação ao play é que ele poderia utilizar algumas ferramentas que já existem, mesmo que existam limitações, com um pouco de raciocinio, poderia ser feito algo muito semelhante senão igual ao que o play é hoje. E esse é o grande desafio de se desenvolver frameworks, partindo do que já existe, como podemos melhorar? Fazer tudo de novo, é claro que teremos algo melhor. Fazer melhor com a base instalada que é o difícil. Então vejo o play mais como uma proposta de como fazer, do que realmente adotá-lo em larga escala.
Utilizaria o play em algum projeto? Sim.
Mudaria alguma coisa nele? Sim, faria uma camada facilitadora do que já existe, e já configurada, ao invés de criar tudo do zero. Assim a adoção poderia sem bem maior.
No mais, gostei da ferramenta, e vou estudar alguns aspectos mais profundamente. Achei bastante válida a iniciativa.


No responses yet. You could be the first!

Leave a Response

Recent Posts

Tag Cloud

advice annotations aop api aspect bean bytecode compilador configuração crosscuting eclipse framework ide jar java jdk jee jme join point jre jse máquina virtual netbeans pointcut produtividade spring weaving web

Meta

Java Framework Portal is proudly powered by WordPress and the SubtleFlux theme.

Copyright © Java Framework Portal