The Play Framework at LinkedIn

Re:The Play Framework at LinkedIn by brikis98 on Thursday February 21, 2013 @02:36PM (#5259641)

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.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by zmmmmm on Thursday February 21, 2013 @06:45PM (#5261450)

I'm curious if you ever evaluated Groovy?

With optional static typing you can pretty much pick and choose the best mode for each part of your application, which for me seems like nirvana. Even with static typing enabled, I find the syntax more concise and productive in Groovy than I do with Scala (I'm more experienced with Groovy so there's a lot of bias in that though).

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by brikis98 on Thursday February 21, 2013 @07:00PM (#5261541)

LinkedIn has been using Grails for ~4 years. It's a terrific framework, but we found that Groovy was one of the downsides. The language is very easy to learn and use with Java, but we found that it didn't scale nearly as well to large numbers of users or developers. It's worth noting that this was pre Groovy 2.0, so I'm not sure what has changed in the latest version of the language.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by zmmmmm on Thursday February 21, 2013 @07:07PM (#5261584)

Thanks - that's really interesting to hear. It sounds like your use predated 2.0, at which time I would certainly have said the same thing. However static compilation (a feature of 2.0) has definitely changed my feeling about it - you're getting compile time type checking and near-Java speeds, but all the highly expressive Groovy syntax still works.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by vorg on Thursday February 21, 2013 @08:00PM (#5261828)

> you're getting compile time type checking and near-Java speeds

The static compilation added in Groovy 2 is much faster than dynamically-compiled code but is still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.... It was written by one developer, and first shipped in Grails only 2 months ago, which doesn't even seem to use the static compilation features (correct me if I'm wrong). Let the Groovy/Grails developers eat their own dogfood first before recommending Groovy's static compilation to others.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by smrtinsert on Thursday February 21, 2013 @03:15PM (#5260017)

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?

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by brikis98 on Thursday February 21, 2013 @04:24PM (#5260524)

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.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by smrtinsert on Thursday February 21, 2013 @06:18PM (#5261304)

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!

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by chaostheory on Thursday February 21, 2013 @03:28PM (#5260127)

If I were to guess, it would be configuration, more specifically the myriad number of choices and combinations of it. Spring's strength and weakness is the power of customizing it.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by johnx123-up on Friday February 22, 2013 @01:47AM (#5263074)

Thanks for the insights. But, why not Scooter http://www.scooterframework.com/ or ActiveWeb https://code.google.com/p/activeweb/ ? Both look quite comparable with RoR than Play!

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by rybosome on Friday February 22, 2013 @02:40PM (#5266248)

Does LinkedIn make use of Play's async response features for anything public facing? That's a feature that I am very curious about.

[ Parent | on HN ]

Re:The Play Framework at LinkedIn by brikis98 on Sunday February 24, 2013 @04:55PM (#5276082)

Our Play frontends are entirely reactive/non-blocking, so yes, we're using the async features very heavily. We'll have a blog post about this in the near future.

Our Play backends, if they use JDBC to talk to a database, are fully blocking, since pretty much all JDBC drivers are blocking. One of the nice things about Play is it's easy to configure the thread pool to handle this configuration as well.

[ Parent | on HN ]