Play Framework - Felipe Oliveira

Why Did I Fall in Love with Play! Framework?

by Felipe Oliveira · 44 comments

in Play Framework

Some time ago, I was the tech lead for a few very large deployments on the Real Estate market for companies like Fannie Mae, Freddie Mac, Foreclosure.com and HUD. We were running that traditional enterprise Java stack you are probably familiar with—Spring, Hibernate, Solr, etc. It took a few years but we had built a very nice system; it performed well but deep inside I felt development wasn’t as productive as it should have been. I also noticed that the whole dev process wasn’t as fun as it used to be. Of course, I had heard a lot of great stories about Rails, Django and, more recently, Node.js; there were actually some compelling stories surrounding those technologies. I ended up spending a fair amount of my spare time working on those technologies, and I actually had a really great time building some small apps and prototypes with them. But then I would wake up the next morning, go to work, face another big important project and go right back into my tried and true: Java. 

One of those projects was an online offer management system for Fannie Mae which was to receive a billion dollars in offers in its first month. In my mind, there was no way I would introduce a brand new language—especially a scripting language like Python or Ruby—to the team for such an important project. From personal experience, I feel it’s difficult to manage a large project without type checking. I was basically between a rock and a hard place because I wasn’t very excited about the options in the Java space, and I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc. At the same time, I wasn’t about to give up on Java as a language, especially on the JVM which I grew to trust because of its reliability. 

Then I ran into Play; it was love at first sight for me. (I’d love to tell you how I ran into Play … just follow me on Twitter—[@_felipera] so I can beat Justin “Beaver”‘s Klout score!) Once I decided to take it for a ride, I was up and running right away! With a simple command, “play new”, the whole application structure was defined. Follow that with another simple command, “play run”, and I was ready to get the party started! I felt instant relief because I didn’t need to come up with all those XML files, Spring’s applicationContext.xml, the web.xml, Hibernate’s HBM files, and THEN figure out how to wire them all together! Even after years working on those technologies, I still had to copy and paste them from somewhere; I could never remember all that syntax. 

Another obvious compelling point for me was Play’s ability to reload classes on the fly without having to re-deploy the entire application or restart the server. I think we all know what it’s like to be working on an application, make a change to a class, execute maven or ant deploy … wait until a war is packaged … copied to a deploy directory … wait for the servlet context to get destroyed … then wait some more for the application to be deployed. And THEN … once the application is FINALLY deployed, we open the browser, hit our development environment and THERE’S A BUG! The problem could be as simple as a single character misplaced somewhere. It doesn’t matter what the problem is, we still need to go over that entire process all over again. By the third or fourth time that happens, the developer zones off on Slashdot, Hacker News or whatever his/her favorite website is. Play handles class reloading beautifully; you really don’t have to restart your server!

I was also attracted to Play’s Stateless model, that “Share Nothing” HTTP architecture. Many of us were unfortunate enough to have developed, and even worse, supported J2EE-based applications that were built on a Stateful model. It was really hard managing state, cluster-safe cache objects, HTTP sessions, especially for those Enterprise Java Beans (EJBs) and that whole concept of attached objects. Play doesn’t share state between each node which simplifies the management of your cluster, and it provides a cluster-aware and cluster-safe caching solution.

Man, I could go on and on all night but I’ll spare you from all my craziness! In a nutshell, Play is a full stack framework for modern Web applications with a NIO-based development and production servers, full support for MVC, a persistence engine, a fully integrated testing framework (unit testing and functional testing), a powerful async Web Service client, an async-based job manager, multiple extensions are available through modules, support for full customization on the framework behavior through its plugin mechanism, dependency management, validation framework and even more advanced features such as WebSockets.

I don’t know if you guys know this but I’m an old man; I’ve been developing Web applications for 15 or so years now. And for the most part, with undying passion. But Play has rejuvenated my love for developing Web applications all over again. 
 
This is—more than anything—a declaration of love,
Felipe Oliveira

Now Go Play!

Article by Felipe Oliveira

{ 4 comments… read them below or add one }

opensas from Buenos Aires, Distrito Federal, Argentina August 25, 2011 at 7:26 AM

excellent post, you should post it dzone
you really show your love for play! with all the effort you put everyday spreading the word and developing modules for it, great work!

Felipe Oliveira from San Francisco, CA, United States August 30, 2011 at 3:01 AM

Hey man I have published the article to DZone, I am a MVB there but I had totally forgot. Thank you for the reminder!

ceefour from Jakarta, Jakarta Raya, Indonesia October 26, 2011 at 8:47 AM

I fully understand your bias. And I don’t have anything against Play framework. But please try to be more objective and informational (than persuasive).

The first strength (and the first of everything should actually be the ‘most’, else you lose the reader’s interest) you mentioned is : “play new” & “play run” –> how different is this to Spring Roo and Seam Forge? You mentioned Spring Roo, so this one is hardly a unique feature of Play.

Defining XML configuration files : these are also generated by Spring Roo and Seam Forge. Not new with Play. In fact, Spring Roo and Seam Forge generates standard (Spring/Java EE) XML config files, so the developer can tweak them if needed, reusing the JPA/Hibernate knowledge & skills they already had. With Play, I’m not sure what sort of configuration it needs (or abstracts). Will the developer need to learn yet another way to configure persistence, etc.? That sounds more like a minus rather than plus to me.

Reload classes : Now you’re talking something unique. But you failed to mention JRebel, which is the de facto solution for this problem. Yes, it’s commercial offering, but taken in context with your “very large Real Estate companies” with “billion dollar offer”, that of course has no problem paying hardware and licenses for OS, app server, DB… JRebel licenses would be miniscule in comparison. Comparing JRebel to Play would be a fairer comparison.

Even without JRebel, you said “It doesn’t matter what the problem is, we still need to go over that entire process all over again.” which is not entirely true. Call me picky, but Eclipse IDE in debugging mode can hot-replace Java classes on the fly in some situations, which is pretty useful. Similar capabilities exist in other popular IDEs.

Stateless… Hey I can just use @RequestScoped, nobody forces me to go all-stateful with a JSF 2.x web application. So it’s possible and easy, with JSF, to use the stateless model *and* stateful model, choice is on the developer. That doesn’t sound like a unique strength of Play. It has the opposite effect. It makes the think that Play apps cannot use stateful model, which seems like a weakness … or even when you say possible, is it easy ? (please don’t reply with “stateful is bad” argument… it’s not the point)

After going on great lengths to explain features that are not-so-well described (it’s the description that can be improved, I am sure the features themselves are awesome), you finish the article with a feature list, which are quite interesting: “NIO-based development and production servers, full support for MVC, a persistence engine, a fully integrated testing framework (unit testing and functional testing), a powerful async Web Service client, an async-based job manager, multiple extensions are available through modules, support for full customization on the framework behavior through its plugin mechanism, dependency management, validation framework and even more advanced features such as WebSockets.”

Take for example WebSockets. Now that’s new! I haven’t heard something like this be part of JSF (at least not yet), now the article would be *much* more interesting had you market this as one (of many) defining, unique strength of Play! While it may be a little bit out of context (how is WebSockets relevant to development of very large real estate web applications?) but it’s definitely a more valid argument than implying “play new/run” is better than Spring Roo. Come on!

Note that I’m not affiliated with ZeroTurnaround, VMware/Spring, nor JBoss at all… but I highly respect objective articles. I have heard a lot of great things about Play framework, so please explain Play in a way that is representative of its high quality.

yasin from Turkey November 20, 2011 at 7:34 PM

Thanks for the article. Very informative but I have still hunger for Play information :)

{ 40 trackbacks }

Previous post:

Next post: