I’ll do a small series of posts describing, in a little detail, the Dolphin architecture and the reasons for making the choices I’ve made. Today I’ll focus on the Play Framework. There were many drivers, but I’ll focus on what was most important to me.

1. Scala
2. Scalability & Programming Model
3. Akka
4. Typesafe

Scala

The choice of Scala is a personal one. Many argue it’s fantastic, many argue it’s too complex. I will argue it makes me a better programmer. I won’t get into a language debate here, but I will say that it’s a language that is only gaining in popularity and is arguably the best choice for JVM development today and for the foreseeable future.

Scalability & Programming Model

Play is backed by Netty, the asynchronous event-driven NIO framework. I don’t want/need all the Java Servlet legacy. NIO gives me much better throughput and lower latency. Play also gives me a stateless programming model that allows me to scale out if necessary. In terms of developer productivity, Play’s roots came from a group of developers that wanted Rails-like development productivity without the Ruby baggage shortcomings. They wanted a Ruby-esque cruft-free language, but they weren’t willing to give up type safety and a decent runtime to get it. Who wouldn’t want that?

Akka

Dolphin integrates with many esi.manage nodes. I need a scatter/gather type data-flow capability and Akka gives it to me, very naturally and efficiently with the actor programming model. That combined with NIO gives me a very scalable solution, with even one server node.

Typesafe

Typesafe spent much of 2012 hiring the some of the best Scala developers out there. Some would argue they’re hoarding! ;-) Martin Odersky, their Chairman and Chief Architect, is the main author of Scala and has endorsed both Akka and Play as part of their technology stack. Typesafe is well funded and I don’t see them going anywhere soon.

I’ve moved Calgary Scala over to Google+ Communities. With the combination of Communities, Events and Hangouts, I think Google’s offering has surpassed Meetup.com as the best service to manage Calgary Scala.

I’ll see you in 2013 at our first Calgary Scala Community Event!

I’ve been thinking about web application architecture for a while now. I’ve taken many client-side and server-side frameworks for a spin over the last six-to-nine months. I’ve built prototype after prototype. I’ve learned a lot. I think I’ve learned enough to be innovative yet commercially responsible. It’s time to take the next step.

Dolphin is a project that will bring together an array technologies that I’ve been testing for a large portion of 2012. 2013 will be the year where those efforts will finally produce a commercial offering. Dolphin will not only deliver new value as an integrated product in the the 3esi application suite, it’ll uncover a delivery vehicle for the future generation of 3esi products.

I’m excited to get started.

I find myself in a bit of a conundrum. I’m building a new, modern, web-based application and not only do I have to pick a technology, I have to pick an architecture. I think it is fair to say that these days its a tough choice because we have more options than we did even 5 years ago. First things first, I’ve made the decision that Scala will be the server-side language. I have my reasons, and this is not a Scala versus XYZ post - that choice has been made. I’ve also sucummed to the fact that we’re on the web (in the cloud with today’s jargon), so I’m not even going to try and get away from Javascript.

Now, assuming Scala, most people would probably jump to either Play! or Lift. Probably Play! given it’s endorsement from Typesafe, but I think I have another more important question that needs answering first. What’s the architecture? If I want a very rich client, do I really need more than a simple stateless service layer based on the fact that we’ll have a tonne of Javascript anyway? I’m not sure it’ll be a single-page webapp, but is something like BlueEyes or Spray.io potentially the right choice? Lift and Play! are much more heavyweight in that they take on much more responsibility. They generate the HTML and for these frameworks, the browser can be fairly dumb. Things like routing, validation, Ajax and Comet support are all server-side concerns. Because the browser is more capable today, rich, interactive features are normally implemented by generating and injecting Javascript from the server.

My question boils down to this. Do I go with a traditional Lift/Play! framework where the server takes on both the client and server responsibility or do I go with a rich client + REST-style service layer where the client takes a more prominent role in the application? An architecture where the client deals with routing, validation, binding, etc. I’m seeing frameworks like Angular.js, Ember.js, Backbone.js,… I’m not going to list them all but suffice to say that they all take on some of these framework features from a client-side perspective.

If I choose Play!, am I giving up some of that rich UI? What about situations where I want to provide service API’s for integration/mashup/mobile purposes? How would Play! help me here? Clearly BlueEyes plays well here. I need a service layer regardless.

If I choose BlueEyes, what does my client code look like? How many of these Javascript-based frameworks do I need to give me what I need? Do they scale from a development perspective? I still want my core business-logic in my service layer, but routing, binding.. all that UI stuff would be a concern of the client.

So many choices… I’d love to hear your thoughts.