Scalatron Build.sbt file to the rescue

Scalatron

I’ve been recently playing around with writing a bot for Scalatron however I didn’t find any great explanation on how to setup a nice development process with SBT. The closest I could find was this blog post but it left a lot to the imagination. I hope you find my annotated Build.sbt below better and more clear!

If you launch sbt and run play you should see the Scalatron server start up and pickup your Bot!

Spray – Building a website

Spray what?

So for my current ongoing project we’ve been using the excellent Play! Framework; which although primarily designed for websites we used it for an API WebService. So I figure I’d do the opposite with Spray. Spray is a http framework for building web services on top of Akka actors. The next few posts will probably be around some patterns I did in getting a MVP Login demo that accepts UserPassword or OAuth[2] providers.

The following is the specific commit which I believe I’ve achieved enough of an MVP if you’d like to later browse how its done.

Composing Routes

All the examples on the Spray website show the DSL for the Routes in a single class however I found this to be confusing and exploded to be too large. There are two options people have discussed when composing routes:

  1. Create multiple HttpService actors. Have the main actor forward the RequestContext to other actors based on some route prefix
  2. Use a trait to easily compose the routes that will be given to the runRoute method of the single HttpActor

Although option (2) sounds less everything on Akka ideal, it was the option I chose as I found it very easy to bootstrap and the results were fantastic.

SQS , Apache Camel & Akka

Akka Apache-Camel Via SQS

This is an example project of how to setup a sample project using Akka, Apache-Camel and SQS together. Never heard of them or curious how they interact with each other?

Apache-Camel

Apache Camel is a rule-based routing and mediation engine.

What that basically means is that Apache Camel provides a common API for exchanging messages across a variety of platforms/protocols such as: HTTP, SQS, AMQP

Akka

Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM.

What that basically means is that Akka is a framework for writing code (known as actors) that lend to code to be easily distributed.

SQS

Amazon Simple Queue Service (SQS) is a fast, reliable, scalable & affordable message queuing service.

Why should you care!?

I’ve recently had the pleasure of releasing some code on heroku using the PlayFramework. Although deployment and initial setup was a breeze, I was bummed out to find that using Akka’s protocol was not doable as only standard ports on heroku are allowed (80,443). This leads to being unable to use Akka actors in a proper distributed model (i.e. they can’t talk to each other!)

Heroku has made a post where they outline using RabbitMq instead of the default Akka protocol however I did not find simple / ideal.

This brings us to this sample project! Leveraging Apache-Camel & SQS it was very straightforward to send messages to distributed actors.

Please check out the project on my Github page: https://github.com/fzakaria/Akka-Camel-SQS

Unit test in Play! Framework with Slick

Testing

The play framework includes some pretty good integration/documentation on how to perform testing however most of it relies on requiring a Play! application to be created (i.e. FakeApplication) and the fact that they share the same database. The second point was the more troublesome one, since in ScalaTest the tests are run in parallel. The following is what I have done to get around these problems.

The above code makes re-use of the Evolution plugin provided by Play! The code creates Evolution objects (which contain UpSQL and DownSQL statements) and we can apply them on a before / after method before each test.

Scala Closure Example

Somewhat more real example

Closures aren’t new to me. I’ve used them a bunch when I’ve done JavaScript however I felt like the concept of a closure was really well defined/understood in JavaScript. Although I was aware you could likely (wasn’t sure until I google’d) do it Scala, every example online infuriated me!
Every example was pretty trivial (i.e. summing function) and used a global variable.
I wanted to give a better example!

Example

Play! Framework with Akka actors on Heroku

Play! Framework

Recently for a project I’ve gotten to know the Play! framework and really the Scala language. The introduction into Scala was a very interesting curve, as I feel like I’m constantly flipping back and forth between having a solid understanding and a complete wtf confusion as I learn deeper pragmatic/idiomatic scala code. I have grown to love functional programming and can’t wait to flex some of the map / Option / fold / reduce in the new Java 8 language. Working with the Play! framework was a great first choice as there seems to be a good community and documentation however with any project the more complex it becomes the farther you go from being able to find good examples and into ‘icky’ situations’

Akka

I think you can’t get far into learning Scala with at least hearing about Akka and how cool it is. You read the introduction about Akka in plenty of Play!/Scala books and start to imagine how you’r architecture will look when everything is this beautiful encapsulated Actor. I’ve found however some nifty roadblocks setting it up and this blog post will pretty much be a brain dump on some of the issues I’ve resolved; namely cause of non-interoptiability with Heroku

So you want to use Akka with Play! ?

You want to use Akka with Play! ? Great! Play! actually bundles an Actor system already defined which is managed by the lifetime of the web server (whatever that really means) and come preconfigured to do some X thing which isn’t very clear. The first issue I ran into however is that I wanted to have Akka Actors to perform general book-keeping which meant they would have to be somewhat managed so that only a single instance is running every interval (i.e. Singleton). This sounds like it should be doable with Akka thanks to their SingletonClusterManager however you quickly learn that remote actors are not possible on Heroku. Bummer!

There is a blog post from Heroku on how to setup an Akka cluster using RabbitMQ as their event bus but it just seemed like way to much overhead for my simple use case. Here is some general steps to get Singleton Actors working in Heroku. The overall plan will be to nest a sub-project within your Play! application which contains it’s own Main class that will launch all singleton actors. This sub-application should then be launched only on a single dyno.

Setup a sub-module

Understanding the need for a sub-module is important or at least why I chose to do it this way. The way in which Heroku launches a Play! application is via a start script which is created from the SBT Native package installer when the stage command is executed. You can view the file for your application by opening up target/universal/stage/bin/ and you can see that is launches a NettyServer.scala class.

We could have easily included additional Main methods within our Play! project and included a worker in the Procfile which executes a java target (like what is happening within the run script) however I wanted to leverage the script which meant a new module/project has to be created (limitation of the SBT packager is that it only supports one main method per project). Much of the steps are followed idential from http://www.playframework.com/documentation/2.2.x/SBTSubProjects

Here are some interesting notes:

  • Don’t forget to set that the sub-project is an aggregate so that commands waterfall down to the inner project
  • If you want to re-use the configuration file from the higher project, make sure you reference the path now accordingly
  • Procfile entry: actors/target/universal/stage/bin/actors -Dconfig.file=../conf/application.conf -Dprocess.type=actors