A equipe do Play na Typesafe liberou a versão 2.3 de seu framework web para o Java e Scala. Uma das primeiras mudanças que os desenvolvedores notarão trata-se da ausência do comando play, que foi substituído pelo Typesafe Activator. Ele continua suportando todas as opções do comando original do play, mas também chega com suporte para projetos templates e uma interface de usuário com base em browser como uma alternativa ao console do Play.
O Play 2.3 também apresenta um ferramental evoluído para recursos estáticos através do sbt-web. O Sbt-web fornece um framework comum para plug-ins sbt como sbt-coffeescript, sbt-less, etc, que manipula os recursos do lado do cliente. Ele também inclui suporte ao WebJars para o Play. Por exemplo, a biblioteca Bootstrap agora pode ser incluída através de uma única linha de configuração:
libraryDependencies += "org.webjars" % "bootstrap" % "3.0.0"
A biblioteca de template do Play também foi movida para ser um projeto próprio e renomeada para Twirl, tornando mais fácil o uso de um sistema de templates de terceiros. Outra biblioteca extraída do Play foi o cliente de Web Services.
Além destas reorganizações do framework, o Play 2.3 também suporta o recém-lançado Scala 2.11 (a versão 2.10 também é suportada), e melhorias na API para tornar o uso do Play no Java 8 mais agradável (a documentação demonstra exemplos de sintaxe tanto do Java 7 como o Java 8).
A camada de acesso simples ao banco de dados do Play chamada Anorm, melhorou o suporte para construir consultas com interpolação de string:
SQL"SELECT * FROM table WHERE id = $id"
Se estiver usando o Typesafe Slick, então a integração play-slick estará disponível como um plug-in.
Trabalhar com web sockets sempre foi conveniente no Play através do Iteratess. Na versão 2.3, também é possível conectar um websockets diretamente a um sistema de atores, de modo que as mensagens recebidas no socket são enviadas para um ator e as respostas podem ser enviadas através do socket para o cliente (veja a documentação com códigos de exemplo).
O InfoQ teve a oportunidade de conversar com James Roper, líder técnico do Play, para descobrir mais sobre o novo lançamento e os futuros planos para o framework.
InfoQ: Pode ser uma surpresa para alguns usuários do Play que o console do Play foi substituído pelo Activator. Qual foi o raciocínio por trás desta mudança?
Em primeiro lugar, preciso salientar que o activator é apenas um wrapper em torno do console sbt, com algumas funcionalidades extras como a habilidade de iniciar uma interface de usuário e criar um novo projeto. O console do Play também era somente um wrapper em torno do console sbt, com algumas funcionalidades extras como a capacidade de criar novos projetos. O console do activator é, portanto apenas o início da substituição ao console do play, é possível criar um apelido de play para activator e não notar nenhuma diferença na experiência do usuário. Quando liberamos o primeiro milestone do Play 2.3, descobrimos que as pessoas não tinham conhecimento disto, e isto gerou alguma confusão ou surpresa, mas na documentação e notas de lançamento para o RC1 temos esperança de termos esclarecido este ponto.
O Activator foi escrito como uma extensão, ou a próxima evolução do ambiente produtivo de desenvolvimento que as pessoas amam no Play. Na Typesafe queríamos utilizar este ambiente de desenvolvimento e ampliá-lo além do Play, desta forma tanto projetos internos quanto externos a Typesafe, poderiam tomar vantagem desta tecnologia. Além disto, gostaríamos de fornecer novas funcionalidades como os templates que a comunidade contribui em contexto de tutoriais, e uma série de novas ferramentas relacionadas ao Play, e por isso este esforço foi feito no Activator, enquanto a distribuição e melhoria do console do Play foi colocada em espera com a intenção que a distribuição e console do Play fossem eventualmente substituídos pela distribuição e console do activator. Isto veio a ser concretizado no Play 2.3.
InfoQ: Ao invés de utilizar o Slick da Typesafe, notamos que o Anorm continua como o componente padrão para acesso a dados no Play. Está nos planos integrar o plug-in play-slick de forma mais contundente ao Play ou ele continuará a ser tratado como um plug-in de terceiro?
A intenção era que no Play 2.3 colocaríamos o play-slick no core do projeto Play, inclusive existe uma solicitação em aberto para isso. Entretanto quando chegamos realmente a rever e mesclar, encontramos um problema. Os padrões de uso mais comum do Slick no Play requerem o uso de alguma abordagem de injeção de dependência. Até agora, o Play tentou permanecer completamente sem opinião sobre injeção de dependência - fornecendo mecanismos para permitir o uso de mecanismos de injeção de dependência em tempo de compilação ou execução, mas não requerendo o uso disto, e fornecendo documentação que é neutra para qualquer estratégia de injeção de dependência.
A definição do uso do play-slick, significaria uma mudança, pois não podemos documentar o uso do Slick no Play sem tomarmos uma postura ou recomendar um determinado tipo de injeção de dependência.
Então decidimos que era hora de mudar isso, que precisávamos dar nossa opinião sobre a injeção de dependência, fornecendo um suporte melhor e incluindo isto como uma boa prática em nossa documentação, mas era muito tarde para abordar esse problema no Play 2.3, então incorporar o play-slick como um cidadão de primeira classe no Play foi colocado em espera e atrasado até o 2.4. Mover o repositório play-slick dentro da organização do playframework é um passo que demos para assegurar aos usuários que iremos suportar o play-slick, e a Typesafe também está comprometida em fornecer suporte comercial para o play-slick.
InfoQ: Muitas das mudanças no Play 2.3 parecem se referir ao processo de modularização do framework. Esta estratégia será mantida para o próximo lançamento?
Sim, penso que é uma mudança natural para qualquer framework em processo de amadurecimento. Inicialmente, faz mais sentido empacotar tudo, pois isto remove o atrito ao modificar APIs, permitindo ao framework melhorar e entregar novas funcionalidades de forma mais rápida. Com as APIs tornando-se estáveis, as vantagens de modularizar se tornam mais visíveis, isso significa que componentes individuais podem ter o próprio ciclo de lançamentos, o que leva a correções nos módulos podem ser entregues de forma mais rápida, e torna possível outras mudanças pontuais, que de na abordagem anterior seriam impossíveis, devido às nossas regras de compatibilidade binária rígidas. No Play 2.4 estamos planejando como alvo modularizar nosso suporte para bibliotecas de bancos de dados individuais.
InfoQ: Falando sobre o próximo lançamento, é possível compartilhar o que está planejado para o Play 2.4 (ou mesmo 3.0)?
Publicamos um roadmap atualizado. Note que o roadmap não é igual a uma promessa! Mas as maiores funcionalidades para o Play 2.4 devem ser a estratégia de injeção de dependência, suporte inicial (possivelmente experimental) para streams reativos e akka-http, e uma melhora na experiência de deploy (unificado através da plataforma Typesafe).
No Play 3,0 esperamos ver a erradicação do estado global do Play, e vamos definitivamente ver a introdução de streams reativos como a API IO de base no Play. Isso irá abrir a possibilidade de executar IO assíncrono em todas as partes do Play para usuários Java bem como a possibilidade de escrever parsers de body customizados no Java, em contraste com o que temos agora que são APIs um pouco limitadas para casos de uso específico.
InfoQ: Obrigado pela entrevista!
Após fazer o download do novo Play 2.3, não se esqueça de dar uma olhada no guia de migração para ver quais mudanças são necessárias para aplicações já existentes.