
The Play Framework at LinkedIn - fatiherikli
http://engineering.linkedin.com/play/play-framework-linkedin
======
alpb
I used Play! for more than one and half a year and I must say I have mixed
feelings about Play! now. Before 3 or 4 years ago, your chances with getting a
web application easily in JVM languages was using J2EE ecosystem or Spring
framework. But now there are plenty of alternatives. When Play! came out, it
has done really a good job, it was working just fine, it was magical and it
totally nailed it. But then frameworks evolved around languages like Groovy
and Clojure and they nailed it as well. Best move Play! made so far was
supporting Scala, because all existing Scala web frameworks were crap (yes I'm
talking about Lift).

I used Play in a startup backend and I won't be able to say I was satisfied
with it. Play v2 is especially slower on your local development box,
compilation takes some time and I actually still like Play 1.2.x family more.
Its memory consumption was horrible on production (I made really a lot jvm
adjustments and could not get it properly).

Personally, I now like Python frameworks (e.g Flask) and they are much easier,
but I am not sure if you should rely your whole service infrastructure or
enterprise software on a dynamically typed language stack. There are companies
out there achieved this but I think Java or Scala will be just fine for
LinkedIn, and by the way why the hack they don't allow comments on their
engineering blog?

~~~
taeric
Care to expand on why Lift is crap? (I still have paltry experience with it,
but I also still feel it has the best template mechanism out there.)

~~~
TylerE
I spent quite a bit of time evaluating Lift for some fairly significant (2
man-year+) projects. My final conclusion is that while it is technically
brilliant, and many of the concepts make a lot of sense, it's just very hard
come up to speed on and be productive in, especially if you aren't already a
Scala wizard. Any Lift project is likely to have a fairly low "bus factor" if
you don't already have multiple strong in-house Scala folks.

I had some technical concerns as well - in particular the database
connectivity stuff is a bit painful.

~~~
taeric
Hmm.. I'd never heard of the term bus factor. Amusing concept. How do you feel
Lift compare with the likes of Play?

I can say that the few small things I pushed out with Lift greatly benefited
from the fact that the views were strictly html. To the point that nobody else
involved even had to learn scala. Even though they did make some changes to
the scala code. Being able to let folks edit that to their hearts content was
ridiculously nice. That is, the fact that I did not have to (a) educate
everyone on the templating mechanisms or (b) split apart templates received
from someone else was huge.

As for the database connectivity, I guess you didn't like the agnostic
approach they took?

~~~
TylerE
Re: Templating

I can see how that's a factor for some, but since around here I'm also the guy
who writes all the HTML it isn't really a factor one way or the other.

Re: Databases

Yea, ActiveRecord tends to spoil one. I don't like any of the Java ORMs nearly
as much as AR, or SQLAlchemy for that matter.

Re: Play

I like Play a lot less than Lift. Lift I could see using for a personal
project. Play I could not. It's just like Rails but crappyier and with all the
java headaches and baggage.

~~~
mercurial
> Yea, ActiveRecord tends to spoil one. I don't like any of the Java ORMs
> nearly as much as AR, or SQLAlchemy for that matter.

That's a funny thing to say considering the huge difference in philosophy
between Active Record and SQLAlchemy.

------
ratpik
Was excited to check out Linkedin using Play but then the reasons highlighted
in the article almost let me down.

I am comparing to Python frameworks and Node and everything mentioned there
has been available in the Python stack for a while and now Node (extra points
for realtime websockets stuff).

As per the post Play boasts of:

Rapid iteration, Reactive (only for the server not the client), Open,
Supported, Flexible, Java & Scala

Maybe I would consider Java & Scala just for the enterprise community scale
but definitely not the only one for functional paradigms or rapid iterations.

Everything else is there in other modern web frameworks in Python, Javascript
& even perhaps Ruby.

Probably a new thing for Java but why the choice? Is LinkedIn constrained to
use the JVM?

~~~
brikis98
LinkedIn is primarily a JVM shop. We believe that type-safe languages like
Java and Scala are a good choice for building performant and reliable systems
that scale to huge numbers of users as well as huge numbers of developers. We
aren't constrained to the JVM - for example, we use node.js for our mobile
server - but it has significant advantages and we have years of investment in
it.

Unfortunately, we found developer productivity in the Java/Scala world to be a
huge problem. We also found that most Java/Scala web stacks, based on
servlets, were far behind other web frameworks (RoR, Django, etc) in terms of
keeping up with the requirements of modern web development. Play helps on both
fronts: it dramatically improves developer productivity and handles all the
requirements of a modern web stack (MVC, web sockets, powerful routing, easy
JSON handling, DRY form handling, etc).

Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive
programming model is dramatically better than JavaScript's callback mess), in
some ways no (e.g. it's hard to compete with dynamic/interpreted languages for
pure reload time). Is it better than everything else in the Java/Scala world?
We think so.

~~~
smrtinsert
Developer productivity is really broad. Can you elaborate? Most modern webapps
I work on end up as json services and the backend are just java pojo services
that can be unit and int tested - tdd with java is extremely fast in my
experience.

the whole servlets/jsp/jsf thing is dead imo, is that where you guys were
losing time?

~~~
brikis98
We had Java services that produced JSON, some that used JSPs, and a variety of
others. TDD works in some cases, but if you ever wanted to do manual testing -
for example, actually _see_ the UI you were working on with real data - that
meant redeploying the server after every change.

Play makes this dramatically faster/easier. TDD is better with Play as well:
the plugin support, strong test tools, and sbt's ~test command are amazingly
productive.

~~~
smrtinsert
Personally I rarely test all ui because QUnit verifies all frontend code so
long as it meets the json contract.

Regardless, thanks for your post, I'll give Play a go!

------
j-m-o
Awesome. I've been using (playing?) with this framework for a bit over a year
now and absolutely love it, I'm glad it's catching on as much as it is. The
fact that Heroku and the Cedar stack supported has probably helped user
adoption a ton.

I'm actually using Play 2.0.x for my first independent venture, which I posted
a Show HN about a few hours ago:

<http://news.ycombinator.com/item?id=5258059>

<http://www.tryringo.com>

------
hendershot
I like Play, currently using for a personal project. But ultimately looking
forward to the day where frameworks are replaced by mixing and matching
libraries where you get just what you need and wire it up exactly how you want
to without any limitations.

On the JVM and especially since version 2.1 Play is one of the most
lightweight/modular frameworks. At it's core it's just a fast/async http
server. So why can't that just be a library you pull in and fire up in a main
method?

You can have an IDE or somthing like sbt recompile your changes on the fly so
you can get rapid feedback. Ultimately more rapid feedback comes for automated
tests vs refreshing your browser and verifying something manually (unless it's
UI/lookandfeel changes which are not generally limited by having to compile)

~~~
SourPatch
Those libraries exist. See netty, webbit.

~~~
hendershot
Yup. Play is built on top of Netty and adds value so my point is why not build
it as a re-usable library (or set of libs) vs a Framework, it's really not any
more difficult.

~~~
swah
I enjoyed the ideas on [http://johannesbrodwall.com/2010/03/08/why-and-how-to-
use-je...](http://johannesbrodwall.com/2010/03/08/why-and-how-to-use-jetty-in-
mission-critical-production/) for similar reasons.

------
brown9-2
How do you do DI with Play? It seems as if everything is oriented towards
writing static methods:

\- controller methods are static

\- DB access using the framework seems to involve calling
play.db.DB.getDatasource()

\- Play's Cache API involves calling Cache.get(), Cache.set()

Are Play applications easy to write unit tests for? Does it involve
reconfiguring the framework to use some sort of stub services rather than the
real DB/Cache implementation?

~~~
brikis98
Play actually has a really nice plugin system, which we used extensively to
integrate Play at LinkedIn. The plugin system offers lightweight support for
DI. For example, to use a FooPlugin, you don't use it directly, but ask Play
for an instance of it:

FooPlugin foo = Play.current.plugin(FooPlugin.class); foo.doSomething();

What instance you get depends on configuration (typically, a play.plugins
file), which makes it easy to swap out implementations at test time. Much of
Play's built-in functionality is implemented as a plugin too, including the DB
code, so writing unit tests is pretty simple. There is strong support for
"fake applications", integration tests, etc:
<http://www.playframework.com/documentation/2.1.0/ScalaTest>

We'll blog more about Play plugins in the future.

------
dwhitney
At Pellucid Analytics we're using Play 2.1 with a similar success story to
LinkedIn's. The undersold feature IMHO is the asynchronous responses: with the
excellent new monadic scala.concurrent.Future interface, you can more easily
put together non-blocking web apps with code that looks slick and concise

------
kirang1989
This is definitely a big step towards making Java reputation suck less and
increasing the popularity of Scala.

~~~
chaostheory
Java is a 2nd class citizen for Play and other Typesafe projects like Akka. I
think this helps the jvm and scala, but I'm not so sure about java.

~~~
jlward4th
Java is a first class citizen for Play & Akka.

(I work for Typesafe.)

~~~
chaostheory
As a user of your stuff, it doesn't feel like it. It's been a few months, but
I always felt the Java documentation and samples were lacking compared to
Scala. Then again things may have changed.

~~~
jlward4th
Can you point me to some bugs or examples of this so we can get this fixed?
Thanks!

~~~
cellis
Here's one example: ReactiveMongo, the only async db library ,is only for
Scala.

~~~
eeperson
Is reactivemongo actually tied to play in any way? It seems like it is a
completely separate library.

~~~
cellis
It uses Play's iteratee feature. Also integrates seamlessly with play. My
point is that, while the Play _team_ might develop for Java and Scala
concurrently, the Play _community_ most definitely is Scala first.

------
seivan
Wow, this is actually great news. Play framework looks amazing.

------
cpprototypes
Does anyone else feel templating is outdated tech? I feel like these days you
can just do this:

\- build json rest backend in whatever (java jaxrs/jersey, nodejs express,
etc)

\- build UI with html css js

\- If initial page load is an issue due to lots of ajax calls, then use server
side templating to ONLY insert a single variable which would contain a json
object. This way the initial load is fast since the json is templated directly
into the page. After load the UI calls rest services to get more data.

I've found that this enforces a clean separation of concerns.

------
rama_vadakattu
WE have written lot of code in Play 1.2.X all of a sudden they migrated to
Play2.0 without any backward compatibility.This is sad.

WIth Play2.0 they introduced Scala Many folks has the opinion that Scala is
complex, and i also lost trust in play because of no backward compatibility
and i stuck up with huge code base which is not backward compatible

now iam looking build my other new applications on frameworks like Ruby on
Rails , django leaving play.

------
DigitalSea
While I don't doubt Play is useful (I haven't personally tried it just yet)
I've noticed big tech companies seem to be wasting their time building new
frameworks instead of helping improve already existent frameworks in need of
new ideas and fresh eyes. Why a new framework? Is it really not a
straightforward process to contribute to an already established open source
framework for your desired language?

~~~
brikis98
Play is an open source project that has been around for a few years. In fact,
that's one of the big selling points for us: we're not inventing something
new, but using something the community is using, and contributing back to it.

------
izietto
What did they use before Play?

~~~
skcin7
LinkedIn is scattered. They use a lot of different technologies. It looks like
they will only be using Play in a few of the services that they offer.

------
michaelahlers
I've embraced Play! on a few projects, and my experiences have been great.
There's no need to expand on existing sentiments, but I will say: this
tutorial is excellent. Wish I'd had this when I first got started!

~~~
hhandoko
There's actually a couple of books coming for Play v2.

Play for Java : <http://www.manning.com/leroux/> Play for Scala:
<http://www.manning.com/hilton/>

------
Apocryphon
Is it just me, or is Google's Play Store also having a greenish triangle (set
at the same exact angle) sort of confusing? I've never heard of the Play
Framework, is it related?

~~~
shellac
Play predates the Android store rebranding by several years. They're not
related.

------
tucaz
Reading people's comments here make me laugh a little bit. ASP.NET MVC been
around a few years now and does that and a lot more in a very easy way and in
a great platform. I find it really funny how people get commodity software and
dress up as the next big thing.

It's pretty much the same as when Microsoft announced nuget after ruby gems
and apt-get existed for so long. Why don't they just cut the bull out and call
it for what it is?

~~~
clhodapp
What should they call it? And for that matter, what is "it"? I'm thinking you
probably mean Play, but you might also mean Nugget.

~~~
tucaz
Im talking about both. They should put it as a nice tech or whatever but not
as something never done before.

"One of the favorite features in Play" is being able to show errors in the
browser and not in a log? What year is this? 1995?

~~~
hhandoko
I work with ASP.Net MVC primarily (since v1), but I think Play framework have
a lot to offer in the JVM web development space.

The biggest key selling point for me is the 'hot' reloading: make changes in
your code, refresh your browser, and see the changes immediately. You don't
need the whole project to be rebuilt. As far as I am aware, this is what makes
Play unique. The 'hot' reloading is probably the reason why it's useful to
show nicely formatted errors in the browser (during dev / debug mode), you can
see immediately where you stuffed up soon after browser refresh. Errors are
also pushed to the console.

However, I realise that ASP.Net MVC View templates can be updated during
debugging session, I only wish to be able to do the same with the .Net classes
without having to rebuild it.

Plus, being on the JVM you'll have plenty of PaaS deployment options for cloud
hosting provider (e.g. Google App Engine, Heroku, OpenShift).

~~~
tucaz
With ASP.NET if you are in a 32 bit machine (who still is?) you have edit and
continue so you can do the same as in Play. AFAIK they are working to bring
that to 64 bit machines too.

Don't understand me wrong. I see a lot of value in Play. My only beef is with
the "this the awesomest thing you'll ever see" approach to selling it.

------
rvkennedy
I have to say I've been wondering for a while what happened to LinkedIn - what
used to be a great service has lately taken to a great deal of UI misbehaviour
and dysfunction - to the extent that I'm now relucant to go near it for fear
of its hangs, jumping menus, and repeated reloads. Perhaps this has been
teething trouble switching frameworks?

------
i386
Is there any support in Intellij or Eclipse for their templating language yet?
This has been holding me back from using Play.

~~~
chadrs
Yes; IntelliJ 12 has this.

------
untog
I thought LinkedIn was using node? Or was that only ever in their mobile app?

~~~
pplante
That was just the mobile app. It mostly just acted as a gateway to the other
backend systems.

------
angelohuang
For me, the good thing about Play is the platform support. Play 2.X is fully
supported on Heroku which makes developers to hack something out really
quickly.

~~~
hhandoko
Exactly, and let's not forget OpenShift and Google App Engine :)

------
papsosouid
>Rapid iteration: change the code, refresh the page, and see the change
instantly.

I see the play people tout this all the time, and I assume it is in reaction
to an assumption of dynamic language people that you have to manually compile
every time you make a change. But it is really misleading. You make a change,
refresh the page, and wait 10 seconds for it to compile and reload. Iteration
speed was just as poor with play as it was with bloated J2EE monsters on
jboss.

~~~
eloisant
This is mostly due to the Scala compiler being a bit slow. The team at
Typesafe is working on that, but if you don't want to wait just buy a decent
recent machine with a SSD and you will get back the snappiness you had with
Play 1.

~~~
laureny
> This is mostly due to the Scala compiler being a bit slow.

True. Reloading pages on Play 1 (Java) took less than a second. It's about ten
seconds now on Play 2 because of Scala.

The move to Scala feels like a mixed bag to me: it added both features and
bloat to Play. Play 1 feels so light and fast in comparison.

It seems to me the Play developers moved to Scala more for personal fun than
for their users (nothing wrong with that, just making an observation).

~~~
zmmmmm
I wish they had gone with Groovy. Groovy 2.x offers pretty much all the
benefits of static compilation and dynamic language features together, it
compiles on the fly instantly (being at its heart a dynamic language), and has
meta programming features (intercepting it's own compilation and changing the
AST, etc.) that would rival Scala's.

There's a project out there somewhere for integrating Groovy with Play but it
looks quite immature.

~~~
nnq
When Groovy's author said he prefers Scala
([http://macstrac.blogspot.ro/2009/04/scala-as-long-term-
repla...](http://macstrac.blogspot.ro/2009/04/scala-as-long-term-replacement-
for.html)) it pretty much sealed the language's fate... though, in all
seriousness, there really is _too much language diversity_ on the JVM (how tf
would one choose between Groovy, JRuby or JPython? - yeah, you choose the
framework not the language, but still, it means that all the good developers
are split working on different projects).

~~~
don_draper
That statement is misleading. James Strachan left Groovy a long time ago.
Guillaume Laforge has lead the project from almost death to one of the most
popular languages in use today.

~~~
vorg
Most of the _technical_ work has been done by Jochen Theodorou. Others who
have helped _technically_ are Paul King, Cedric Champeau, Alex Tkachman, and
Jeremy Rayner. James Strachan also did a lot of _technical_ work on Groovy in
his day. I'd rather listen to what someone who's done _technical_ work has to
say than someone who shows powerpoint slides.

You mentioned Guillaume Laforge as leading the Groovy project, but from my
experience, Graeme Rocher, the Grails Project Manager, seems to have far more
say over Groovy's direction.

As for calling Groovy "one of the most popular languages in use today", it
figures fairly low in most popularity ratings (e.g. not in Tiobe's top 50),
and only shows the occasional burst when it's been actively talked up, e.g.
just before a conference when the project managers are selling conference
seats.

