4 ms·

We're using Play pretty heavily at our startup though not for our customer-facing frontend, that's still in Rails. What we love about Play: * Async everything

by saryant 13y ago

We're using Play pretty heavily at our startup though not for our customer-facing frontend, that's still in Rails. What we love about Play: * Async everything, especially the web service library * JSON macros * Scala-based templates * Integration with Akka * Support for server-sent events (we use this for cluster monitoring) What we wish was better: * JSON deserialization performance isn't as good as raw Jackson yet. (Our PR regarding this is actually in 2.2, should be better now) * Documentation could be much better, we still have to resort to the API to figure out a lot of stuff I've been using Play ever since the 2.0-RC days and it's definitely made some huge gains since then. We use Akka very heavily, especially its clustering, and Play works well in conjunction with that though there are still some gotchas lurking about. Our backend is one big Akka cluster right now. We've had a few hiccups but overall it's been a hugely enjoyable experience.

zeckalpha 13y ago
Why use a Rails / Play hybrid? I can understand separating the front- and back-ends, but why not stick to one platform through and through? Momentum? Expertise? Marketing?
- saryant 13y ago
  The founders wrote the frontend in Rails before I came on board but it does very little work. Really it just handles authentication and captures OAuth tokens. I imagine we'll move it to Play eventually but right now we're focused on the backend (Play/Akka) because that's where everything really happens.
Nickoladze 13y ago
Sorry if I'm being dumb here, I've never heard of Play before. It is a replacement for Tomcat?
- russ519 13y ago
  Play is a web development framework. It has the capability to run standalone using it's built in http server or it can output a .WAR file that can be run under containers like Tomcat. http://www.playframework.com/documentation/1.2/deployment http://www.playframework.com/documentation/1.2/deployment
  - saryant 13y ago
    Your link is to the old 1.x branch, here are deployment instructions for 2.2: http://www.playframework.com/documentation/2.2.x/Production http://www.playframework.com/documentation/2.2.x/Production
  - sukaka 13y ago
    and play 2.1+ can serve https as well http://www.playframework.com/documentation/2.2.x/ConfiguringHttps http://www.playframework.com/documentation/2.2.x/Configuring.... In practice, play instances are behind a front end server such as nginx for load balancing, https, caching, and virtual hosting. Play's convention for stateless sessions makes it really attractive to scale by adding more instances to the node balancer.
- yareally 13y ago
  Play 2.0 comes with Netty[1] built into it for making asynchronous requests, websockets and REST easier to handle. Netty is what replaces Tomcat unless you choose to use a third party plugin that builds your Play 2.0 website as a WAR file. Also, with Netty, it builds the entire site into a self contained module that you can run with one click anywhere you have the JVM installed (and the dependencies such as the DB if not using the built in H2). I found it useful for quick presentations or portability. [1] http://en.wikipedia.org/wiki/Netty_%28software%29 http://en.wikipedia.org/wiki/Netty_%28software%29
- lmm 13y ago
  No, it's mostly replacement for the spring-web/struts/jersey/etc. layer (though it also has its own templating layer to replace JSP or whaever). You can run it under tomcat if you want to.
vassvdm 13y ago
Also using Play at a start-up, but as a customer-facing web app. It's great for productivity - getting both compile- and runtime errors in the browser kind of means that you have the advantages of Scala/statically-typed languages combined with those of dynamically typed languages. If you're ready to go fully stateless and (mostly) asynchronous/non-blocking, this is the framework for you. I agree that documentation is still lackluster. I would add that although I love the Scala templates, the support for html forms in Scala is a bit clunky. Also there are still a few too many changes requiring code refactoring on minor releases, but I accept those as a byproduct of quick iterations/improvements.
stingraycharles 13y ago
What I never understood is why they embrace rendering templates at the server. Is it simply a matter of "because we can and it's nice for the people that want to use it", or is there a real real reason why pushing raw HTML via AJAX request is better? I always thought the status quo in the web development world was to use a framework like Backbone.JS to communicate with your backend and use a client-side template engine to render the templates.
- kev009 13y ago
  It's optional; nothing forces you to use them vs doing the AJAX du jour. Play templates are particularly speedy though, they get compiled into JVM bytecode. I actually prefer doing things that way and keeping markup and JS to a minimum. It 'feels' faster and more robust to me.
- saryant 13y ago
  We use the templates to render email messages on the server primarily. Note that Play doesn't force you to use the templates, you can plug in your own very easily or forgo them entirely and just push JSON out for client-side rendering. We use that for monitoring our backend Akka cluster: Play streams JSON using server-sent events to the client for rendering Mustache.js templates. I don't know the exact motivation for including compiled templates (we love them) but in practice Play is perfectly happy either way.
- nek4life 13y ago
  If you have an application that doesn't need to be indexed by search engines, yes. If you have a content heavy website the preferable method is still to render templates on the server. It still varies depending on your use case. I wouldn't say that is the status quo at all.
- virtualwhys 13y ago
  I don't know, maybe type safety? Don't forget about Play's truly excellent form generation/validation, and yes, raw speed of jvm byte code. Rails truly (DHH) made a blog post on why they switched to generating html server-side: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...
eropple 13y ago
Fully agreed on a most of this; when Play does something well, it does something really well. I personally just wish the build system wasn't such a mess and so antithetical to good development practices--it's extremely hard to have something like a shared domain library among multiple projects (with hot reloading, i.e. if you need to iterate on it while you develop) without making a fake Play project with a conf directory and all of that. It feels built for independent systems/applications rather than ones that play (ha) nicely with each other. (Also, using the Flyway module has made life a lot easier. play-evolutions is a bit wonky.)
- saryant 13y ago
  You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine. That's how we do it anyways.
  - eropple 13y ago
    Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.
    - joostdevries 13y ago
      Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/org.eclipse.egit.github.core/2.1.5 http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o... If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects. My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala Those two facts make sbt a big hurdle in adoption I noticed.
      - 13y ago

by saryant 13y ago

zeckalpha 13y ago

Why use a Rails / Play hybrid? I can understand separating the front- and back-ends, but why not stick to one platform through and through? Momentum? Expertise? Marketing?

saryant 13y ago
The founders wrote the frontend in Rails before I came on board but it does very little work. Really it just handles authentication and captures OAuth tokens. I imagine we'll move it to Play eventually but right now we're focused on the backend (Play/Akka) because that's where everything really happens.

Nickoladze 13y ago

Sorry if I'm being dumb here, I've never heard of Play before. It is a replacement for Tomcat?

russ519 13y ago
Play is a web development framework. It has the capability to run standalone using it's built in http server or it can output a .WAR file that can be run under containers like Tomcat. http://www.playframework.com/documentation/1.2/deployment http://www.playframework.com/documentation/1.2/deployment
- saryant 13y ago
  Your link is to the old 1.x branch, here are deployment instructions for 2.2: http://www.playframework.com/documentation/2.2.x/Production http://www.playframework.com/documentation/2.2.x/Production
- sukaka 13y ago
  and play 2.1+ can serve https as well http://www.playframework.com/documentation/2.2.x/ConfiguringHttps http://www.playframework.com/documentation/2.2.x/Configuring.... In practice, play instances are behind a front end server such as nginx for load balancing, https, caching, and virtual hosting. Play's convention for stateless sessions makes it really attractive to scale by adding more instances to the node balancer.
yareally 13y ago
Play 2.0 comes with Netty[1] built into it for making asynchronous requests, websockets and REST easier to handle. Netty is what replaces Tomcat unless you choose to use a third party plugin that builds your Play 2.0 website as a WAR file. Also, with Netty, it builds the entire site into a self contained module that you can run with one click anywhere you have the JVM installed (and the dependencies such as the DB if not using the built in H2). I found it useful for quick presentations or portability. [1] http://en.wikipedia.org/wiki/Netty_%28software%29 http://en.wikipedia.org/wiki/Netty_%28software%29
lmm 13y ago
No, it's mostly replacement for the spring-web/struts/jersey/etc. layer (though it also has its own templating layer to replace JSP or whaever). You can run it under tomcat if you want to.

vassvdm 13y ago

Also using Play at a start-up, but as a customer-facing web app. It's great for productivity - getting both compile- and runtime errors in the browser kind of means that you have the advantages of Scala/statically-typed languages combined with those of dynamically typed languages. If you're ready to go fully stateless and (mostly) asynchronous/non-blocking, this is the framework for you. I agree that documentation is still lackluster. I would add that although I love the Scala templates, the support for html forms in Scala is a bit clunky. Also there are still a few too many changes requiring code refactoring on minor releases, but I accept those as a byproduct of quick iterations/improvements.

stingraycharles 13y ago

What I never understood is why they embrace rendering templates at the server. Is it simply a matter of "because we can and it's nice for the people that want to use it", or is there a real real reason why pushing raw HTML via AJAX request is better? I always thought the status quo in the web development world was to use a framework like Backbone.JS to communicate with your backend and use a client-side template engine to render the templates.

kev009 13y ago
It's optional; nothing forces you to use them vs doing the AJAX du jour. Play templates are particularly speedy though, they get compiled into JVM bytecode. I actually prefer doing things that way and keeping markup and JS to a minimum. It 'feels' faster and more robust to me.
saryant 13y ago
We use the templates to render email messages on the server primarily. Note that Play doesn't force you to use the templates, you can plug in your own very easily or forgo them entirely and just push JSON out for client-side rendering. We use that for monitoring our backend Akka cluster: Play streams JSON using server-sent events to the client for rendering Mustache.js templates. I don't know the exact motivation for including compiled templates (we love them) but in practice Play is perfectly happy either way.
nek4life 13y ago
If you have an application that doesn't need to be indexed by search engines, yes. If you have a content heavy website the preferable method is still to render templates on the server. It still varies depending on your use case. I wouldn't say that is the status quo at all.
virtualwhys 13y ago
I don't know, maybe type safety? Don't forget about Play's truly excellent form generation/validation, and yes, raw speed of jvm byte code. Rails truly (DHH) made a blog post on why they switched to generating html server-side: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

eropple 13y ago

Fully agreed on a most of this; when Play does something well, it does something really well. I personally just wish the build system wasn't such a mess and so antithetical to good development practices--it's extremely hard to have something like a shared domain library among multiple projects (with hot reloading, i.e. if you need to iterate on it while you develop) without making a fake Play project with a conf directory and all of that. It feels built for independent systems/applications rather than ones that play (ha) nicely with each other. (Also, using the Flyway module has made life a lot easier. play-evolutions is a bit wonky.)

saryant 13y ago
You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine. That's how we do it anyways.
- eropple 13y ago
  Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.
  - joostdevries 13y ago
    Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/org.eclipse.egit.github.core/2.1.5 http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o... If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects. My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala Those two facts make sbt a big hurdle in adoption I noticed.
    - 13y ago