34 ms·
The Play Framework at LinkedIn
- deleted 14y ago[deleted]
- izietto 14y agoWhat did they use before Play?
- skcin7 14y agoLinkedIn 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.
- kirang1989 14y agoThis is definitely a big step towards making Java reputation suck less and increasing the popularity of Scala.
- chaostheory 14y agoJava 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 14y agoJava is a first class citizen for Play & Akka. (I work for Typesafe.)
- chaostheory 14y agoAs 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 14y agoCan you point me to some bugs or examples of this so we can get this fixed? Thanks!
- cellis 14y agoHere's one example: ReactiveMongo, the only async db library ,is only for Scala.
- eeperson 14y agoIs reactivemongo actually tied to play in any way? It seems like it is a completely separate library.
- cellis 14y agoIt 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.
- benmccann 14y agohttp://play.lighthouseapp.com/projects/82401/tickets/914-java-oauth-docs-missing http://play.lighthouseapp.com/projects/82401/tickets/914-jav...
- haimez 14y agoOr the logger interface. It's awful. Great that you use the sl4j interface, but I can't cast it to that type because it's a wrapper for the "real" logger written in Scala. It's annoying, and agreed- using Java in the Play framework feels more like a "look what else it can do" than an intentional use-case.
- chaostheory 14y agoI just checked it last night. It's much better now. Both Play and Akka documentation and samples for Java & Scala pretty much match.
- taligent 14y agoWell let's be clear here. In Play 1 development happened on Java first and Scala second. In Play 2 development happened on Scala first and Java second.
- deleted 14y ago[deleted]
- brikis98 14y agoLinkedIn uses a service-oriented architecture; the site consists of hundreds of individual services - that is, separate codebases, deployed on separate hardware, built on a handful of different technology stacks. This lets us iterate and scale each service separately depending on its requirements. We've moved some services to Play already and are now gradually rolling it out for others.
- whichdan 14y agoI would absolutely love to read a blog post going in depth about how your SOA works.
- douglasisshiny 14y agoI would, too. I did enjoy reading this article, though. I'm a novice with Rails, and I have been learning Java for a Coursera course (Algorithms), and the handful of things the article went over seemed straightforward. It would be interesting from my perspective to see different frameworks interacting through a RESTful interface.
- seanwoodward 14y agome too.
- seivan 14y agoWow, this is actually great news. Play framework looks amazing.
- untog 14y agoI thought LinkedIn was using node? Or was that only ever in their mobile app?
- pplante 14y agoThat was just the mobile app. It mostly just acted as a gateway to the other backend systems.
- corresation 14y agoLinkedIn is a bit scattered when it comes to technology. They also made a big dog and pony show about how the vast majority of their mobile app is built in HTML5, and why that is the best way to do it. A few months later they made a lot of noise about rewriting much of it in native, and why that is the best way to do it. We had an internal debate about whether to use the wrapped web or native, and it was humorous seeing both sides using LinkedIn, and their vigorous arguments, as the foundation of their positions.
- ikailan 14y agoIt was only the mobile API server. Shameless self promotion: http://news.ycombinator.com/item?id=4615429 http://news.ycombinator.com/item?id=4615429
- papsosouid 14y ago>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.
- jlward4th 14y agoYou should run Play with "~run" which recompiles on file-change. Running with just "run" doesn't recompile until you hit refresh in your browser. This provides a noticeable difference in the "effective" compile time.
- papsosouid 14y agoWe did. The difference is negligable, it takes a fraction of a second to hit f5. In fact, it costs time fairly often as you save the file, notice right away that you have a typo, fix it and save again, but now it is still busy compiling from the first time so you have to wait out two compiles.
- wiradikusuma 14y agoHow about this setup: IntelliJ (catches typo better), SSD (faster disk access), JRebel (free for Scala).
- brikis98 14y agoOn my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test command in sbt for automatically rerunning tests on each change, and the amazing error handling, this is a massive step forward for Java/Scala web development.
- 14y ago
- ratpik 14y agoWas 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?
- ikailan 14y agoLinkedIn isn't constrained to the JVM, as they had some apps running on CRuby 1.8 and node.js, but they do heavily favor the JVM. JVM interop DOES help with much of their existing codebase which is Java heavy.
- ratpik 14y agoYeah I agree to interoperability. Makes it much simpler to have the same Java stack across the distribution. Either way, that's a big boost to Play framework!
- ikailan 14y agoIt's been a while, but there was a lot of use of Groovy on Grails a few years ago for exactly this reason. I was a strong advocate of JRuby when we did run Ruby code, but it didn't get very far.
- dxbydt 14y ago>... Scala...definitely not for functional paradigms I am sorry, what ?
- ratpik 14y ago
- j-m-o 14y agoAwesome. 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://news.ycombinator.com/item?id=5258059 http://www.tryringo.com http://www.tryringo.com
- alpb 14y agoI 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 14y agoCare 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 14y agoI 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 14y ago
- Apocryphon 14y agoIs 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 14y agoPlay predates the Android store rebranding by several years. They're not related.
- brown9-2 14y agoHow 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?
- kasey_junk 14y agoIf you are asking how do you do DI with Play in java, I can't answer your question. If on the other hand you are asking for how to do it in scala, it is quite easy. Scala's language support for traits, implicit conversions, implicit parameters etc. make dependency injection trivial. Once you get used to it, things like test mocks or IOC containers seem like obvious language smells.
- brikis98 14y agoPlay 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 http://www.playframework.com/documentation/2.1.0/ScalaTest We'll blog more about Play plugins in the future.
- atto 14y agoThis shows how to do dependency injection on controllers (using Guice) with Play 2.1, with a sample Play! app. The Java implementation is similar. http://eng.42go.com/play-framework-dependency-injection-guice/ http://eng.42go.com/play-framework-dependency-injection-guic... For Play! components, they don't hole you into one DI framework or another. Instead, you can use your favorite DI framework (or with Scala, the cake pattern) on top of any Play API calls.
- dwhitney 14y agoAt 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
- michaelahlers 14y agoI'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 14y agoThere's actually a couple of books coming for Play v2. Play for Java : http://www.manning.com/leroux/ http://www.manning.com/leroux/ Play for Scala: http://www.manning.com/hilton/ http://www.manning.com/hilton/
- hendershot 14y agoI 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 14y agoThose libraries exist. See netty, webbit.
- hendershot 14y agoYup. 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 14y agoI enjoyed the ideas on http://johannesbrodwall.com/2010/03/08/why-and-how-to-use-jetty-in-mission-critical-production/ http://johannesbrodwall.com/2010/03/08/why-and-how-to-use-je... for similar reasons.
- DigitalSea 14y agoWhile 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?
- saryant 14y agoI'm not sure such a framework already existed for Java and Scala. Which one should Typesafe contribute to if not Play?
- taligent 14y agoPlay is not new. It's been around for years and was the first Java framework of its kind. You know in the time it took you to write that you could have Google'd this information.
- brikis98 14y agoPlay 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.
- tucaz 14y agoReading 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 14y agoWhat 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 14y agoIm 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 14y agoI 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).
- 14y ago
- i386 14y agoIs there any support in Intellij or Eclipse for their templating language yet? This has been holding me back from using Play.
- chadrs 14y agoYes; IntelliJ 12 has this.
- angelohuang 14y agoFor 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 14y agoExactly, and let's not forget OpenShift and Google App Engine :)
- cpprototypes 14y agoDoes 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.
- rvkennedy 14y agoI 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?
- rama_vadakattu 14y agoWE 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.