Category Archives: Play

Reactive Manifesto – First Reactions

While visiting the Play Framework website, I noticed a new banner in the top right corner. Perhaps “new” isn’t correct – I’ve been almost exclusively in Node.js and Rails land for the past 6 months, so I might be behind the times on this one.

Screen Shot 2013-11-10 at 10.18.14 PM

Following the links takes us to The Reactive Manifesto. As of December 6, 2013, the manifesto has 3098 signatures, and a quick google search shows that the term is taking off pretty quickly. So, I decided to dive in for a quick read, and see what, if any changes it might suggest for my development style.

This architecture allows developers to build systems that are event-driven, scalable, resilient and responsive…
-The Reactive Manifesto

In General…

  • The manifesto seems to encourage some behaviors that I really like.  For example, event-driven systems are a big part of reactive applications.  As a concrete take-away, I certainly like the idea of using lightweight message queues as a way to decouple event publishers and subscribers.  And while we are at it, let’s stay away from clumsy, closed systems like JMS, and stick to open, Polyglot platforms like RabbitMQ and ZeroMQ.
  • Resiliency.  This is the part of the manifesto that I should probably spend the most time absorbing.  As much as I hate it, I’ve written Node.js apps in the past that would crash the whole server on uncaught errors.  The classic problem of Cascading Failure shouldn’t be nearly so prevalent.  Treating errors as “events” rather than failures makes your app way more resilient.
  • Big servers are for suckers.  I know a few Sys Admins still get their jollies from putting together big iron setups, but all the cool kids are scaling horizontally.  Multi-threaded applications, and the complex, proprietary technology behind them, is less attractive than single event-driven, non-blocking processes.   The Reactive Manifesto, at some level, is a guide for writing distributed systems that are resilient in their software design, but also targeted at the physical resiliency of cloud computing.

With My Java Developer Hat…

  • If you like developing in the Play! Framework, you’ll already like a lot of what the manifesto has to say.  No surprise, due to to fact that Typesafe seems to be the driver behind the manifesto.  In any event, a few obvious features that Play! provides for Reactive Applications
    • Play! (unless you opt-out) runs on, a asynchronous, event-driven application server, that supports Non-Blocking io.  The Reactive Manifesto (quite accurately) points out that event-driven applications will remain loosly coupled, and perform better than the syncronous, blocking, multi-threaded apps.

With My Node.js Hat…

  • Node.js developers should sign the manifesto, and be proud of the common ground they can find the with Java/Scala developers using Play!.  The event-driven, non-blocking approach works with the Node.js theory perfectly.  A couple specific things that sync up well
    • Node Streams implement a lot of functionality for fulfilling the “responsive” part of the reactive manifesto.  The current version of streams provides an intuitive interface, good backpressure controls, and resistance against overloads on traffic bursts.  If you are doing IO, and not using streams, you may be missing out on a big opportunity.
    • Callbacks, Queues, Streams, & EventEmitter all provide nice ways to keep your app asynchronous and message driven.

With My Rails Hat On…

  • This one is a little bit harder.  Don’t get me wrong, I’m 100% sure you can write reactive apps using Rails, I just don’t know that the framework encourages it as readily.
  • Unlike Play! or Node, the web server is a little more of a wild card when using Rails. Webrick, Unicorn, Thin, Puma, etc.  To my knowledge, the only one of those that supports non-blocking IO is Thin, but even that is subject to the blocking aspect of Rails.
  • EventMachine has some nice features for writing reactive, event-based ruby apps.
  • I think I’m going to have to stop there, and work on a who separate post re: Reactive Applications in Rails.

Yes, I signed.  While the manifesto smells too much like a marketing tool for Play!/Typesafe, I can’t hate on a good idea.  Read the manifesto, sign it if you like what you read, and leave me some comments if you think I’m way off base on this one.

Screen Shot 2013-11-10 at 11.35.08 PM


5 ways to Play! poorly

As readers may be aware, I’m really into the Play! framework. It combines the convention-over-configuration mindset of ROR with the Java/Scala libraries and skills that I’ve worked on for years.

That said, Play! isn’t idiot-proof. Here is a list of 5 mistakes to avoid in your Play! projects.

1) Using Modules too liberally

Play modules are great, but they can lead you to develop your projects as if you were still in the same Java world you’d always been in.  For example, when developing a REST api in Play, I started by installing the RestEasy Module  It seemed like a no-brainer – an easy way to implement JAX-RS services.  However, after a bit of development, it became clear that one can obtain all the RESTful goodness by simply using Play routes  There is no reason to deal with increased build times, increased deployment size.

If you need the functionality of a specific module, by all means, include it.  However, spend the extra 5 minutes to see whether the functionality you need is provided in core Play first.

2) Not considering the Scala/Java decision closely enough

This is most relevant if you are working in Play! 1.x.  If you are in Play 2.0, its easy – use scala, please.  However, it can be appealing to use Java for play 1.x projects.  However, I tend to think that it is a bad idea.  The Play! development team is clearly moving towards Scala as the primary language, and it seems like a good idea to start with Scala in your 1.2 projects now.  It should make the 1.2 to 2.0 upgrade that much easier when you are ready.  I expect to have another entry for my readers in a few weeks with some tips on the 1.2 upgrade process.

3) Building a War

Any Java developer knows this cycle.  Build an application, package it into a war, deploy the war to an application server.  Play allows you to use this familiar cycle, and they support lots of popular app servers.  That said, think carefully before you go this route.  The play server and play run commands bring up a standalone server using Netty.  It is fast, simple, and perhaps most importantly, ensures that you are running your application in the same method for both development and production.

4) Fail to worry about Template Performance

Play is fast.  The JVM is a very optimized platform, and play takes advantage of that.  However, play has its Achilles heel –  Groovy Template rendering. I know it, you know it, the play dev team knows it.  Luckily, there are a lot of easy ways to fix this problem is performance is a concern in your app.

  1. Try one of the many alternate templating engines.  FasterGtJapid or Rythm all provide much better speed.
  2. Try Play! 2.0.  The template system has been moved to Scala, which shouldn’t have any of the performance issues.
  3. Go Client-Side.  Play! makes a great REST server, and if you combine it with a client-side MVC framework like jmvc or backbone, you can avoid the overhead of server-side template compilation.

5) Using Getters & Setters

Play! provides a wonderful piece of functionality called properties simulation.  I won’t rehash the details here – in short, Play! allows us to get away from one of Java’s most annoying flaws.  Languages that we’ve come to love such as Ruby, Python, and JavaScript all make do without getters & setters.  Try as I might, I can’t think of any compelling reason that we should use them for every little property in our Java code.  I know it can be a little uncomfortable at first to buck the Java conventions and make your members public.  Trust me, once you get used to seeing those concise, clean models, you’ll love it.

There you have it, 5 Play! framework anti-patterns.  Please comment if you have any anti-patterns of your own to share.

Tagged , ,
%d bloggers like this: