Good afternoon everyone, and welcome to this talk: scalable language; scalable web. My name is Timothy Perrett, and i’ve been kicking around in the Scala community since about the end of 2007; essentially before we had a reasonable collections library, akka, lift as we know it today, or any of the other awesome Scala projects that make up out lovely community. \n\nI like to make things though, and i’ve been involved in a wide range of projects, from web toolkits, to build systems to a myriad of other things. With that being said, I have a big interest in web programming, and its something I care a great deal about: most of the commercial projects I work on these days are web applications or services. \n
I’m also the author of Lift in Action, the most complete guide to Lift available today; so if you have an interest in learning Lift, by all means pick up a copy.\n
So today I’m going to be talking to you about how approaches to web programming have changed over the years, and how the features present in both the scala language and the within our community have influenced “solutions” to the problem of HTTP application programming.\n\nAs this talk is titled “scalable language; scalable web” I first what to reconsider the meaning of the word “scalable”.\n
Scalability has very much become a buzzword in the business community, and we are often bombarded with blanket marketing that implies scalability is directly centred around performance concerns, and performance alone. \n\nWhilst it may be true that online sites and applications are growing faster than ever before, and indeed, at the end of 2011 there were some 555,000,000 sites online. Of that huge number though, only a very small portion are the Facebooks, Googles and twitters of this world. This is something we must consider when discussing scalability. \n\nAs you can see on the slide here, the dictionary defines scalability to mean “Able to be used or produced in a range of capabilities: it is scalable across a range of systems”. Not once does that sentence mention performance or “big data” or anything else suitably buzzword like. Ergo, we can consider this idea of scalability as being multi-faceted, having multiple applicable axis. In this talk I’ll be covering what could be three possible axis of scalability:\n- scaling down: something that is small, lightweight and has minimal overhead.\n- scaling up, or scaling performance: pretty much what the business folks take it as meaning; building the next facebook. obviously. \n- scaling features: scaling an idea; taking a single concept and applying it to everything you do. \n
So before we get onto all that good stuff, I would just like to take you on a trip down memory lane... the year is 1995, and whilst Bill Gates was busy launching his “revolutionary” new operating system Windows 95, James Gosling was busy inventing servlets. \n\nServlets did remain useful after ’95 though, unlike Windows unfortunately for Mr Gates.\n\n----- ERATA \n\nServlets were later formalised by Pawani Diwanji as part of JavaSofts Jeeves project in 1996[1]\n\n[1] http://www.mtvjug.org/Oct23.html\n
Raise your hands if you recognise this code, or something similar to this, or if you’re still maintaing or writing something like this today...\n\nThis style of HTTP programming is 17 years old. When we look at nearly everything else we use today, “old” constitutes 6 months, or perhaps even a year. On that scale 17 years old is practically neolithic! This stuff is dinosaur technology.\n\n\n\n\n\n
Whilst researching this talk I can across this great quote from a 1996 mountain view JUG agenda, which detailed the “Jeeves” project which the servlet API was originally a part of. The agenda states: “Jeeves defines the Java Servlet APIs for the quick and easy creation, installation, administration and security of Java-based network servers.”\n\nThat sounds awesomely whizzbang!... and at the time it really was. Now though, we know we can do better: its not 1995 or 96 anymore; things in our industry have changed, but, fundamentally web programming hasn’t changed on the JVM since its inception. Ok, things have been added, augmented and hastily bolted on, but at its core it hasn’t really changed.\n
This strikes me as diametrically opposed to views on HTTP programming within the wider industry: things have changed irreparably in the past two years or so with the advent of HTML5. Browsers are now capable of delivering better, more seamless user experiences and interacting with richer server-side backends than ever before: event sources and web sockets being just two such examples.\n\nWith the pace of change being what it is, the unfortunate reality is that the servlet specification cannot keep up; the point in case there being the time it took servlet 3.0 to reach release status. \n
Consider for a moment our vibrant Scala eco-system; its thankfully quite different to the Java eco-system, and its full of very smart folks who’ve approached the problem of HTTP programming in a range of different, and innovative ways. These toolkits are numerous:\n- scalatra\n- play\n- lift\n- unfiltered\n- slinky\n- and many more\n\nGetting back to this idea of scalability, the first on my axis of possible interpretations of scalability was scaling down with lightweight toolkits.\n
I once recall hearing a software industry anecdote that said that by increasing application complexity by 25% would boost the development effort by 200%. This is most fascinating, as one has to consider what happens when situation is reversed: remove 25% of the complexity, and slash the development effort and cost of that project. \n\nOf course, this can’t work for every conceivable application, but as per the introduction, many, many applications will never need to scale to anything more than a single instance. \n
Unfiltered is a lightweight, stateless HTTP abstraction that can sit atop many different types of backend server, from our old friend the servlet API, to newer platforms like Netty. In any case, Unfiltered’s API is exceedingly lightweight and solely based around two Scala language concepts: function composition and pattern matching.\n
Intents are just partial functions\n
\n
\n
\n
\n
\n
1. ergo simple learning curve\n\n
1. ergo simple learning curve\n\n
1. ergo simple learning curve\n\n
1. ergo simple learning curve\n\n
1. ergo simple learning curve\n\n
\n
introduction to spray with a quick mention of its blueeyes lineage \n\ninsanely fast: 65k req/s which is slightly faster than netty \n
\n
\n
\n
\n
\n
\n
\n
Architecturally speaking, Spray is entirely built on actors: HTTP Requests are just immutable messages.\n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
This a gross over-simplification of how spray works, but you can visualise HTTP requests as incoming messages to the HTTP Service actor, which in turn spawns a new worker actor with a request context continuation to execute and respond to continue the request processing. \n
\n
\n
\n
\n
\n
\n
talk about lifts security features\n\nImplements its own session storage so the session is fully type-safe\n
introduction to lift \n\nstateful web\n\nOne of the oldest scala projects around\n\n\n
\n
\n
\n
Prevents CSRF\n
Prevents CSRF\n
Templates are validated XML, not a bunch of strings that are simply munged together. The result is that anytime you want to pass unescaped content you have to be very explicit about it, the toolkit forces the developer to understand why he/she is doing that.\n\nThis massively helps in preventing XSS vulnerable code getting into production by accident. \n
\n
\n
\n
\n
\n
\n
\n
\n
In this talk i’ve demonstrated three distinct ways in which Scala has had an impact on the design of web toolkits within our eco-system. Whilst its fairly easy to see that each tool is distinctly different from its fellow projects, there is a degree of commonality throughout, and that’s composition. \n\nFrom core APIs, to higher level routing DSLs and templating: the upshot of highly compassable systems is more modularity, code that is easier to maintain, and far simpler to reason about. \n\nGone are the days of monolithic Spring or JEE systems! HTTP toolkits in Scala let you achieve things that are either not easily doable with servlets, or require a dependency chain as long as your arm to make it happen.\n\n\n
With all that good stuff being said, its important to understand that there are no panaceas, no silver bullets. \n\nThe real take away from this presentation is that most of the HTTP toolkits differ considerably from one another. Each has its own strengths and weaknesses, and its more important than ever to understand your own use case and make the right tooling choice to solve your problem. \n\n\n
With all that good stuff being said, its important to understand that there are no panaceas, no silver bullets. \n\nThe real take away from this presentation is that most of the HTTP toolkits differ considerably from one another. Each has its own strengths and weaknesses, and its more important than ever to understand your own use case and make the right tooling choice to solve your problem. \n\n\n
With that, thank you very much for listening. If anyone has any questions I’d be happy to answer them. \n
With that, thank you very much for listening. If anyone has any questions I’d be happy to answer them. \n