#play! framework

One of the problems with using relatively new languages is the lack of tools around white box automation, unit testing, code coverage etc. These things pile up your technical debt over a period of time.

Play framework and scala do have a good unit testing tool set with ScalaTest, Specs2, Mockito and more. Though I was not able to find a great tool for code coverage. There are tools which do the job, but most of them also profile the play framework code which skews up the results. The best option I found is scct (Scala Code Coverage Tool).

Here is a step by step guide for the least intrusive way to include code coverage in a scala play project and your continuous integration setup. This if for a single project. For multiproject builds, consult scct site.

Add the following code to you plugings.sbt file.

resolvers += "scct-github-repository" at "http://mtkopone.github.com/scct/maven-repo" addSbtPlugin("reaktor" % "sbt-scct" % "0.2-SNAPSHOT")

Update your Build.scala to have these hooks

val scct_settings = Defaults.defaultSettings ++ Seq(ScctPlugin.instrumentSettings: _*) val main = play.Project(appName, appVersion, appDependencies, settings = scct_settings).settings(..

With this, you have the required tool in place for code coverage. Just restart your play project so that the new dependency you have in your plugin file is downloaded. Now run 'scct:test'. If you have unit test cases in play, a report will be generated and put in ../server/target/scala-x.xx/coverage-report/index.html. Use Mozilla/Firefox to open this report and you can see your code coverage.

If you use Jenkins, you can integrate this with your build process enabling you to produce code coverage reports every build, fail the build if code coverage goes below a certain percentage of code and stuff.  To do this, we use Cobertura Plugin in jenkins. The great thing about scct is that it creates a report in cobertura format as well, which enables us to use cobertura plugin in jenkins. 

To start, go to Jenkins->Manage Jenkins and install Cobertura plugin. Then go to the project you want to have code coverage integrated in and click Configure->Add post-build action. You can find this drop down at the bottom most part of the page. Choose Publish Cobertura Coverage Report. This will add a few new things to your build settings. The Cobertura xml report pattern will be something like this "**/target/scala-x.xx/coverage-report/cobertura.xml". Rest of the settings are pretty self explanatory. 

SBT a Simple Build Tool The command-line of Play is SBT, like Ant, Maven or Gradle, but use Scala for DSL.

We will find a Build.scala file into the project folder.

SBT Dependencies The Build.scala file define a sequence appDependencies. We add the dependency as the following image:

It is used in play.Project as a parameter. Repositories In the same file (Build.scala) adding the "resolvers"

CORE PARTS Routing Can be found under the conf folder, the routes file. Here, the row define how to access server-side using HTTP. Each row have three columns: - the method used in the request - a relative path - the action to be invoked

Action An action is a simple method that has a defined route declaring as the code to be executed when a matching request arrives; are declared in a container (a class Java) that extend the Controller.

Just think:     java -> OOP => method     scala -> FP => function Template A template file is HTML mixes with Scala code. We can find into app/views folder, index.scala.html.

To begin understand we will try to get the first results modifying the template index.scala.html to:

and refresh the web browser to see…

But, if the message came directly from Apache? we change the value of the argument of index in the Application controller file.

Or just trying to render a JSON

(see the Content-Type)

From 0 to Play! + Scala

summary:  First Step: Just run Play Framework

Install - Play Framework 2 is a JVM web framework, you must check that Java 6 or higher is installed. - We have to update our PATH. //all examples I will do in Mac.

$> cd ~ $> echo 'export PATH=$PATH:<path-to-play>' >> .bash_profile

Now check if your Play environmentt it's ok typing: play

//try: play help

Create your first web Go where you want to create a project

$> play new <name>

//next choose a name for your project, 1 for Scala

At this point, Play will be created MVC file structure.

$> cd <name> $> run

Open your web browser http://localhost:9000/

Eclipse fan? To generate the files necessary to configure an Eclipse project, inside the project folder type: eclipse.  (or idea)

Then, import project.

Going Asynchronous with Play!

Play! Framework is a high velocity web framework for Java and Scala.

Its a nice framework. Provides you clear MVC, stateless and web friendly architecture. I have been using it for last few months and we at Lucidchart utilize it extensively. I don't want to go into details but for interested people,  you should try and use Scala and find out what new it bring to the table. Play gives you all that and makes kick starting anything easier.

What I want to discuss here is a problem we faced recently. I wanted to have a dashboard where I can see the request serving time of each of my API end points. The use case is pretty common. This information comes in handy when your system behaves weird. It comes in handy when optimizing your web service. It even comes in handy to see the bottle necks of your system. Well I can go on, but the idea is simple. Its a useful matrix and we should be collecting it.

To implement it, I started goggling what people have been doing to get this data out of play. What I found was not good, there is no straight forward or recommended solution. Digging deep, the easiest and non usable way I found was AccessLog module in play. The module, as the author correctly states, is not production ready. Obviously I had to do some more leg work.

The way I had been getting this data till now for other languages/frameworks/web engines was to parse the access log. Access log usually has the request which the system served, the time it was served, time it took to serve the request in milliseconds, HTTP status and some other info. Parse this log properly and you have all the data you need. Unfortunately, Play! uses JBoss Netty as an in built web server and provides us no access log for that. Sad.

So the possible solution.

1) AccessLog Module for Play! Framework.

2) Put Nginx in front and use its logs. If you are already using Nginx, your work is cut in half. Just parse its logs and boom!

3) Do what this guy did. A nifty solution for synchronous requests, which is what we wanted actually.

We just started using this solution with a required change.

This is what the initial solution is.

import play.api._ import play.api.mvc._ object Global extends GlobalSettings { def ResponseTime[A](action: Action[A]): Action[A] = Action(action.parser) { request => val start = System.currentTimeMillis val result = action(request) println( request + " -> " + (System.currentTimeMillis - start) + " ms.") result } override def onRouteRequest(request: RequestHeader): Option[Handler] = { super.onRouteRequest(request).map { case action: Action[_] => ResponseTime(action) case other => other } } }

Elegant, isn't it? Call another function which in turn calls the action. In between that, take the time diff and log.

Now about the needed change. As you might have figured out, "println" wouldn't work for production setup. What we want is to save the response times without having to do a file I/O every request. There are many ways to do it. Let me point out a couple.

1) Keep the response times in memory. Create a map of request.path to response time. Every few minutes, dump that data to a file or DB using a separate job. The issue with this is, you might miss requests since every time you restart your service or anything like that, your in memory data is lost.

2) Write an actor and pass response time data to that actor. Let the actor do the work asynchronously. This will make sure your API response time is not impacted.