Looking at the past years of application development, as a developer you might have noticed a significant shift from desktop applications to web applications. The Web has evolved as the major platform for applications and is going to take over many facets—not only in development but also in everyday life, resulting in this shift accelerating. Who would have thought 10 years ago that current mobile phones are indeed only very strong ironed notebooks with a permanent Internet connection?
The Internet provides a very direct connection between consumer and producer. For application developers this implies a very easy -to- use- and- handle platform. Looking around, many application frameworks have evolved in recent years in order to be very Internet-centric. These frameworks interpret the Web as an ubiquitous platform for providing not only ordinary web pages, as it was done 10 years ago. The web has become a data provider on top of one of the most proven protocols in industry, the HyperText Transfer Protocol (HTTP). The core concepts of the Internet being a decentralized highly available network with HTTP as a protocol on top of it are the inner core of a big part of today’s applications. Furthermore, another development took place in the last years. The browser became more and more a replacement of the operating system. Fully fledged web applications like Google Docs, which act and look like desktop applications, are becoming more popular. JavaScript engines like Google V8 or SpiderMonkey are getting insanely fast to deliver web browser performance not thought of several years ago. This means current web applications are now capable of delivering a real user experience similar to applications locally installed on your system.
So many software engineers today are also web engineers as well. This poses a very big problem. As most of software engineering is based on abstraction, many tools, frameworks, and languages try to hide complexity from the engineer, which sounds good at first. No web engineer cares about the fragmentation of the IP packets which are sent throughout the whole world in milliseconds. By abstracting and layering your software to reduce the complexity per layer, you inadvertently might hide features of the underlying protocol your software is built upon. Many frameworks try to resemble the style of programming desktop applications, with the exception of application being in the Web. However, in order to make use of HTTP and its features you cannot easily hide them away in your application framework.
This is especially a problem in the Java world. The defined standard is the servlet spec, which defines how web applications have to be accessible in a standard way. This implies the use of classes like HttpServletRequest, HttpServletResponse, HttpServlet, or HttpSession on which most of the available web frameworks are built upon. The servlet specification defines the abstraction of the HTTP protocol into Java applications. Though it is quite a good spec as HTTP carries quite some complexity around, it forces frameworks to obey certain conventions which never got challenged in the past.
While many web frameworks like Django, Rails, or Symfony do not carry the burden of having to implement a big specification and do not need to fit into a big standardized ecosystem, most Java web frameworks have never questioned this. There are countless excellent web frameworks out there which implement the servlet specification, Grails, Tapestry, Google Web Toolkit, Spring Web MVC, and Wicket to name a few. However, there always was one gap: having a framework which allows quick deployment like Django or rails while still being completely Java based. This is what the Play framework finally delivers.
This feature set does not sound too impressive, but it is. Being Java based implies two things:
Using the JVM and its ecosystem: This implies access to countless libraries, proven threading, and high performance.
Developer reusability: There are many Java developers who actually like this language. You can count me in as well. Have you ever tried to convince Java developers to use JavaScript as a backend language? Or PHP? Though Groovy and Scala are very nice languages, you do not want your developers to learn a new framework and a new language for your next project. And I do not talk about the hassle of IDE support for dynamic languages.
Shortening development cycles is also an economic issue. As software engineers are quite expensive you do not want to pay them to wait for another “compile-deploy-restart” cycle. The Play framework solves this problem.
All of the new generation web frameworks (Django in Python, Rails on Ruby, expressjs on top of nodejs in JavaScript) impose their own style of architecture, where HTTP is a first class citizen. In Java, HTTP is only another protocol that a Java application has to run on.
So the Play framework is a pure Java-based solution, which brings a real HTTP focused framework with lots of helpers to speed up development resulting in shorter iterations and faster deployments.
This book should help you to get the most out of the Play framework and to be as fast as any other developer on any platform when creating web applications.
I made several assumptions about the persons reading this book. One of the first assumptions is that you already have used Play a little bit. This does not mean that you have deployed a 20 node cluster and are running a shop on top of it. It means that you downloaded the framework, took a brief look at the documentation, and ran through a few of the examples. While reading the documentation you will also take a first look at the source, which is surprisingly short. I will try to repeat introductory stuff only when it is necessary and I will try to keep new things as short as possible, as this is a cookbook and should come with handy solutions in more complex situations.
No book is perfect. Neither is this. Many people would be eager to read a chapter about integration of Play and Scala. When I started writing this book, my Scala knowledge was far from competitive (and still is in many areas). Furthermore I currently do not think about using Scala in a production web application together with Play. This will change with growing maturity of the integration of these two technologies.
Alexander Reelsen