Fri, 22 February 2013
Episode 29: James Roper on Play 2
  • Joined by James Roper, committer to the Play 2 Web Framework.
  • James started as a Play user, later submitting patches and questions, eventually being hired by Typesafe to work on Play full-time.
  • Play 2's philosophy
    • Play 2 is a full-stack web framework aimed at making web development simple in both Java and Scala.
    • Developers should have everything they need to implement most typical needs, out of the box, without configuration.
    • The latest web technologies should be first-class, not bolted on.
  • The Play 1 -> Play 2 transition had a few goals
    • Change the architecture to make modern web technologies (WebSockets and Comet) first-class citizens.
    • Make (idiomatic) Scala a first-class citizen.
    • Benefit from Scala's greater opportunities for type checking.
  • Why did Play grow in popularity so fast? Probably because it's just the kind of thing Java developers were waiting for after learning about the fast iterations of Rails.
  • IO
    • Play is built on Netty.
    • Play provides an Iteratee library for doing IO with Netty.
    • Netty is intentionally not exposed, to prevent the framework from being locked in.
    • The body is generally in one of four formats, each of which has a built-in parser:
      • URL-encoded form
      • Multi-part form
      • Json
      • XML
    • However, structure for custom body parsers/streamers is provided.
  • Interop with the Java ecosystem that expencts blocking streams is possible, if not recommended
    • You can convert input streams into Enumerators.
    • Play is tuned for non-blocking so you need to have enough available threads in the thread pools to handle that blocking.
    • Play is designed to make it easy for your app to scale, so blocking is not recommended whenever it can be avoided.
  • Routing
    • It's completely statically typed and checked at compile time.
    • External routes file compiles to Scala code.
    • Reverse router lets you reference routes in a safe way.
    • There's also a Javascript router.
  • Compilation performance
    • This is one of the biggest criticisms of Play, so the developers are focusing a lot of effort on this.
    • Avoiding provoking unnecessary compilation from the Scala incremental compiler is a top goal.
    • Modularization of routes files and apps helps reduce compilation times.
    • Java developers are particularly annoyed because they're used to javac speeds, not scalac speeds.
  • Java vs. Scala
    • The Play 1 -> Play 2 rewrite caused some vocal opposition by Java developers.
    • There's far more people that are happy with it than are not.
    • Play 2 is trying to stay ahead of the game with respect to modern web technologies. Some of the alienated developers may actually be alienated by the changing web landscape.
  • Server-side templating
    • ScalaTemplates (aka Twirl) are compiled to Scala files.
    • Since the template language is just about one special character (the @ symbol), understanding the language and compiling it is easy.
    • James is pleased that Twirl is now available as a vanilla sbt plugin for other web frameworks.
    • Twirl isn't a DSL for XML or Json, so it's not as DRY as languages like Jade or Scaml.
    • You can bring in Scalate yourself if you'd like that. It doesn't type-check template invocation, only the code within a template.
  • Binding
    • Binding is built right on the case class apply and unapply methods, plus some validation.
    • The Java API uses Spring data binder, which uses reflection.
  • Json
    • The Play Json library is built on Jackson, adding some wrappers for idiomatic Scala development.
    • In 2.0.x Jerkson was also provided for those wanting to bind to and from models using reflection. It wasn't encouraged since Scala can avoid reflection.
  • Persistence
    • Slick integration is on the roadmap, but can be used as-is right now.
    • Slick's string-based interface does something similar to what Anorm does. However, Anorm isn't going to disappear.
  • Async
    • Responses can be wrapped in an async result if you have reason to think it will take a while to respond.
    • The WS API allows you to make web calls, a common reason for slow responses, with the async aspect handled automatically.
    • In the case of delays caused by intensive computations, you may want to dispatch the operation to another thread pool that is tuned for it, using Akka's Future type.
    • Interestingly, Play suspends the TCP request regardless of whether you use the async function or not. The async function only indicates you want to do asynchronous IO.
    • Long-polling is easy, you just use a Future result. Whenever you redeem the future the result will be sent.
    • Comet sockets are h andled through enumerators.
    • WebSockets are handled differently, because they aren't HTTP. In Play you return a Pair[Iteratee, Enumerator] to handle those.
    • No pipelining support yet due to a bug in Netty.
    • Play's cache doesn't deal with the Thundering Herd Problem. Piping through an actor can potentially solve that problem.
  • Criticisms
    • Build times are the biggest criticism.
    • Alienation from Java developers, especially surrounding the inability to read Play's source code.
    • Play 1 features that are not present in Play 2.
    • Scaffolding is much desired to generate logical actions that you fill in during development. It doesn't make sense for Anorm, but may make sense during Slick integration.
    • Is Play heavyweight? It's not a library, it's a framework, you don't put Play into your project, you put your project into Play. Play 2.1 modularizes things more so less is in your classpath by default.
  • What's next?
    • Play 2.2 will make the getting started experience even smoother.
    • Check out Play Mini.
    • Alternate back-ends?
    • Play is very interested in Spray, especially spray-io, which will provide deeper integration with Akka, including Akka clustering. Play could switch Netty for Spray today, but the real challenge is how to harness the benefits of Spray's actors while still providing Spray's Iteratees model. Spray tells, Play asks. Investigations continue.
    • Servlet 3's async support looks bolted on, as opposed to first-class, so James is concerned that a servlet back-end could be limiting. At best it would be a way to support servlet deployment, not a way to integrate with the whole servlet ecosystem like Atmosphere. Servlet 3.5's async IO may improve things, but maybe not enough.
    • Play is looking to support the client-side a lot more, including Javascript framework integrations, Javascript dependency management, exposing server-side models to Javascript, and shared templating.
  • Community
    • Currently contributing many bug fixes and filling out features.
    • To get involved you should find an area you're passionate about and start implementing a feature.
Direct download: 029-james-roper.mp3
Category:interview -- posted at: 8:28 PM

Syndication

Feedback

License

Archives