Modern web applications increasingly require us to move from static web content to a more dynamic paradigm where a lot of integration happens in the background and the user interaction is more and more sophisticated. At the same time, the provided online services need to adapt to the changing business requirements and scale to elastic loads, that is, handling peak hour traffic. Finally, in addition to the service they provide, web applications now tend to collect extra information concerning user interaction to better understand customer behavior. In this chapter, we are going to tackle the following topics:
- Understanding what makes applications reactive
- Introducing the processing of streams in Play Framework with the Iteratees pattern
- Writing reactive applications including web sockets
The traditional pull model adopted by the Web, which is used to browse HTML pages now needs to be seconded by two-way communication. This includes a push model where users, for example, receive confirmation of asynchronous and long-running services or just get notifications of various natures.
The recently created Reactive Manifesto, which is available at http://www.reactivemanifesto.org, aims to summarize the criteria that characterize reactive applications in a technology-agnostic way:
- React to events: Message-passing architecture, not wasting the time waiting for resources
- React to load: Focuses on scalability by avoiding contention on shared resources
- React to failure: Build resilient systems with the ability to recover at all levels
- React to users: Honor response time guarantees regardless of load
Without going into the details of the manifesto that you are encouraged to read, we can directly see that the notion of message-driven architecture, which was used by Akka in the previous chapter, fits very well with this reactive model. In the following sections, we are going to focus on examples of building such web applications on top of the Play Framework.