Play Framework has lost its relevance. Or has it?


The last few weeks, rather months have been very interesting for Play Framework at least at Knoldus. We end up working and custom developing large sophisticated products and very niche reactive products. Over the last few months there has been a healthy (the part where people starting pulling each others hair is omitted on purpose) on whether we should be using the Play Framework at all. The usual suspects being the client side html generation hippies who would not buy the Play philosophy at all and then we have the Play Framework fan boys who would not code in anything but Play. I carried on this debate to the Scala Days conference in SFO and also discussed it with Typesafe’s Rich Dougherty (@richdougherty) to get an idea about his thoughts. We decided to do a rundown of all the pros and cons of one approach versus the other and this is the list that we came up with.

Client Side Rendering

Here, client code drives everything from reacting to user input, querying the server for data using APIs which in most cases would return JSON, presenting the resulting data back to the user. Backbone, Angular, Ember etc would be good illustration of this strategy.

Advantages of client side rendering

  1. High Re-usability – The back-end code only needs to spit out JSONs. There could be n number of clients for the same service who would be consuming these JSONs on the webapp level as well as mobile.
  2. Front end can be tested in isolation from the back end.
  3. The front end is totally independent of the back end and the back end can be swapped out to a different language. We did this when we converted the back-end of a product from Node.js to Scala. Read our ServiceSource case study.
  4. Saving power on the server – Well, I would debate this one, but this came up as an advantage that we are pushing the processing to the client machine than the server.

Server Side Rendering
Here, the server decides what the client should render. The pieces of HTML returned by the server may contain complex client-side behaviour, which may include client-side HTML generation. This behaviour however would be limited and might not suit well for all the desktop like client applications and front ends.

The advantages are as follows

  1. Code is type-safe, cleaner and easier to debug.
  2. There are set standards for writing server side code. Ok, with the advent of frameworks in js there are very well defined standards in js world as well, but how many of us follow them.
  3. It is faster to generate and send back HTML from server. Twitter moved from server to client only rendering and them moved back to server side rendering only to realize load time gain of 400% across different browsers.
  4. Server side rendering requires a constant time over load but client side rendering defines a linear increase with load.
  5. Content is visible to search engines for better indexing.
  6. There is less data going down the pipe.

In general the mantra to remember is that it is a bad practice to send JSON if all that we are doing on the front end is to incorporate that JSON in page’s DOM structure. Also it is a bad practice to send HTML to the client side when the client would need to parse the HTML and do some calculations with that.

So what is the best strategy?

In my opinion, it is a hybrid approach. That means instead of delivering JSON data and baking them into the template on client side, you could render the template on server side. Once the page is loaded, next the smaller interactions come into play, thus AJAX call has to append html templates to the DOM instead of processing JSON data.

Play has a robust templating engine which would allow us to define HTML generation in a type-safe manner and then render it on the client fast. Hot reload for all code, templates, config changes, etc allows you to iterate much faster. The stateless design of the framework helps you with performance and also enables you to write non-messy code. Play is also an amazing combination of best practices like non blocking and is built on Akka thereby getting the resilience and concurrency support. Finally LinkedIn, Guardian, Klout and other high scalability sites use play which endorses its value.

So does that mean Backbone and Angular have lost the battle? No, but they need to co-exist with Play. I would propose to always render the first view with Play templating and then make JS based calls to the server to generate JSON for rendering portions on the page based on user actions. Thoughts and brickbats welcome 😉

Advertisements

About Vikas Hazrati

Vikas is the Founding Partner @ Knoldus which is a group of software industry veterans who have joined hands to add value to the art of software development. Knoldus does niche Reactive and Big Data product development on Scala, Spark and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). To know more, send a mail to hello@knoldus.com or visit www.knoldus.com
This entry was posted in JavaScript, Play Framework, Scala and tagged , , . Bookmark the permalink.

12 Responses to Play Framework has lost its relevance. Or has it?

  1. Imho, using Play for the backend and scalajs (scalajs-react) for the frontend it’s probably the best solutions.

  2. So you say it’s lost its relevance because you don’t use its HTML API entirely? But you’re still using its backend stuff aren’t you? BTW you’re completely right, using it with a mixture frontend is a good way and it’s a really productive web framework.

    • Greg, I would say that we use the HTML generation (templating) as well as all the backend stuff as well. The magic happens when we are able to tread the fine line between how much (HTML) to generate on the server side and how much of client side rendering needs to be done. The post is more an food for thought for the Angular / Bakbone fanboys who would rather want to all the stuff on the client side including the DOM rendering just to keep play out 😉

  3. Play has suffered from Second System Effect ! And it would always remain a geeky toy with limited scala fanboys community.

    I would use following Java Play alternative Stack today,

    Server Side Back End
    http://www.ninjaframework.org/

    Stateless ORM – Avaje EBean for Typesafe Data Create/Update
    http://www.avaje.org/

    JOOQ for Typesafe Data Query/Read
    http://www.jooq.org/

    Server Side Typesafe Templating
    http://rythmengine.org/

    Try this stack before making nice comments ! It’s a well though stack for a sane Java Developer.
    If you don;t like above stack, you can Go for Spring Boot ! But Play has suffered from Second System Effect !

    • Rakesh, Play has a tremendous adoption and it is just not a SSE. With quite a few top enterprises using it, it has a strong adoption and community support. With us being focused on the Scala Ecosystem, Play is a very viable option with us and the best part being that it is based on Akka thereby inheriting all the goodies of fault tolerance and scalability. It would soon get the Akka HTTP support as well there by making it even cooler 😉 Thanks for sharing your thoughts on the Java stack, but apart from templating, i would not be able to draw parallels almost anywhere as for FRM we would use Slick (not Anorm), Reactive drivers for asynchronous reads from DB and Scala / Akka backend support for business logic. Of course all of this would be tied together with Play. If the stack that you mentioned works well with Java then in all fairness you should go with that depending on how comfortable you are with Java as compared to Scala.

  4. Avni says:

    You should look at ROCA-Style: http://roca-style.org/

    • Avni, I think my issue with Roca style is again the same thing which is the core focus of this post.
      “ROCA splits into two parts: The server-side and the client-side architecture. The server-side consists of RESTful backends, serving human-readable content as well as services for machine-to-machine communication, either public or internal. “

  5. I completely agree with the hybrid approach and this is the one we have taken at Qudini. We take the approach of rendering data the user needs to see on first load within the Play template then use Angular.js making requests against a RESTful API which is also served up by Play. I’d say that around 90% of the controller methods in our Play app are just serving up JSON. The main benefit of this is we are able to reuse them for the native mobile versions of our application.

  6. dxxvi says:

    If we use the mentioned hybrid approach, then in single page applications, we use Play to render the first page only once, don’t we? And that first page is usually very small (a login page or some home page with some brief information). That means any template thingy (like freemarker, velocity, thymeleaf, mustache, jsp …) will work. Am I wrong anywhere?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s