spray for Web Development

Even though sprays development focus so far has not been web applications but HTTP-based integration layers, you can of course use it for powering browser-based GUIs as well. The recent trend of moving web application logic more and more away from the server and into the (JS-based) browser client as well as the increasing availability of good SBT-plugins for things spray itself does not provide (like view-templating or LESS- and CoffeeScript-Support) might even make such an approach gain attractiveness.

Currently a spray-based web development stack might consist of (a subset of) these components:

spray-can HTTP Server The web-server. Receives HTTP request and sends out responses. Optionally terminates SSL. spray-routing The routing layer. Handles requests depending on URI, parameters, content, etc. and (un)marshals to and from the application-specific domain model. Forwards higher-level job requests to deeper application levels and converts the respective results into HTTP responses. Serves static content. sbt-revolver SBT-plugin for hot reloading of changes to any type of sources (scala, twirl, CSS, LESS, JavaScript, CoffeeScript, images, etc.) without the need to restart the server. Can deliver an almost “dynamic-language” type of development experience. twirl SBT-plugin providing for view-templating based on the play 2.0 template engine. less-sbt SBT-plugin for compilation of LESS sources to CSS. coffeescripted-sbt SBT-plugin for compilation of CoffeeScript sources to JavaScript. sbt-js SBT-plugin for Javascript and Coffeescript compilation, minification, and templating. SLICK Library for elegant database query and access. spray-json Library for clean and idiomatic JSON reading and writing. sbt-assembly SBT-plugin for single-fat-JAR-deployment. A client-side frontend framework One of the several established client-side JavaScript frameworks.

While a stack like this might not provide everything that a full-grown web framework can offer it could have all that’s required for your particular application. And, because you can pick the best tool for each individual job, the resulting application stack is a lot more flexible and possibly future-proof than any single framework. Of course the downside of this approach is that integrating the different components is now on your shoulders. Also, there is no single point of contact for support and upgrades.

Still, combining a client-side JavaScript framework with a spray-based application backend could prove itself as an interesting alternative to a “classic” server-side web framework. We’d love to hear about your experiences in this regard...