A Week On The Road With James Ward
March 31st, 2013 by Mike Kelland
We’ve just come back from an awesome week on the road with James Ward. We had a great time full of microbrews, cigars and hiking stories but most importantly talking to a lot of people about Typesafe. In all, we did 11 presentations over 3 full days in 3 cities in Ontario and Quebec. The response was amazing! Or maybe I should say, the “reaction” was amazing!
The word of the week was “Reactive”. There’s a lot of interest in the reactive programming model right now – it’s something that we’ve been doing with” work arounds” in traditional frameworks. Reactive basically boils down to two concepts; asynchronous and non-blocking. To put it into the web context, frameworks traditionally have handled large volumes of requests by running in a single thread, optimizing that thread like crazy and then forking multiple copies of themselves to handle a bunch of different requests at the same time. This is fine if the goal is generally low volume, very traditional websites or even single-tenanted or medium scale SaaS. There are two major trends that are squeezing the juice out of this model. First, from the top, applications are being written more and more in multi-tenant SaaS models – centralizing the application, multiplying the number of users and keeping them all on a single instance of the application. Second, from the bottom, the hardware designers have basically decided that single threads are almost as fast as they can get and, for the last 5-10 years, have been concentrating on increasing the number of threads per chip. The end result is that, if you want to put together a successful application, you need to build for massive scale and if you want massive scale at a profit, you need to optimize in parallel with the hardware. Reactive programming allows you to do this.
Under the Play Framework’s reactive model, threads are seen as resources to be shared across the entire application. Instead of allocating a thread per request and then holding that thread until the request completes, Play allocates a thread to accept the request, makes its request to the slow parts of the app (like the database) and releases the thread to be used by another request. When the response comes back from the slower parts of the app, Play allocates a thread again to generate the response and sends it back to the requestor. This whole process happens while the connection from the user remains open.
This model, combined with Play’s stateless architecture which enables very robust horizontal scalability, got a huge “reaction” at all of our presentations.
The other thing that generated a lot of interest was Play’s ease of development. This is a framework that invites comparisons to Ruby on Rails and Python Django. To those that we met who were used to those frameworks, there was a lot of excitement that robust, scalable languages like Java and Scala could be used in such a productive and rapid way. To those from the traditional Java world, the ability to create a working web project in seconds and then deploy it without worrying about containers and the Servlet model – and most importantly doing so without having to write or generate any XML – was a massive eye opener.
To everyone we met on our travels – whether at the Ottawa, Toronto or Montreal meetups or our various meetings over the course of the week – thanks so much for having us and sharing this exciting technology with us!