This document discusses the origins and principles of reactive web applications. It began with a 1985 paper on reactive systems and was further defined in 2013 with the Reactive Manifesto. The four principles of reactive applications are that they should respond to users, scale to load, be resilient to failures, and be event-driven. Reactive technologies like Play Framework use asynchronous non-blocking techniques for better resource utilization compared to traditional threaded approaches. Key concepts for building resilient reactive applications include supervision, actors, and reactive streams.

1. Reactive Web Applications
Juan Sandoval
@juanitodread

2. Origins
“On the Development of Reactive Systems” was published in 1985 by David Harel and
Amir Pnueli.
Systems are stimulated by the external environment.
Systems continuously respond to these stimuli.
A refined definition:
Systems are available to continuously interact with their environment.
Systems run at speed that is dictated by the environment, not the program itself.

3. The Reactive Manifesto
Puts “Reactive” word in the map again.
Published in June 2013.
Describes a new architecture.
Four principles:
Responsive: React to users
Scalable: React to load
Resilient: React to failure
Event-driven: React to events

4. Reactive technologies

5. Play Framework...
Full stack framework

6. Threaded vs Evented web servers...
Threaded server:
More HTTP requests reach the server than there are worker threads; users
connecting to the application have to wait……………………….
HTTP requests taking too long to process are cancelled; the user may see a page
with HTTP Error 408 - Request timeout.
Too many requests queuing up can cause users to leave the site. =(

7. Threaded vs Evented web servers...
Evented server:
HTTP requests are transformed into events that represents smaller pieces of work.
Transformation is done by event handlers that performs those tasks and may
produce new events.
Tasks need to be small.
This model only works if the entire pipeline is asynchronous (non-blocking I/O).
Event handlers send notifications when the work is done.

8. Threaded vs Evented web servers...
Evented servers has a better use of hardware resources than threaded servers.
Threaded server rely on thread mechanisms, this means some problems…
Shared mutable state (One thread have access to the same memory space, open files handles, and
other shared resources as other threads) = Side effects
Complexity programming model using locks.
Scala is a language that encourage use of immutable state (no side effects
problems)... (Play Framework is written in Scala with an API to be used by Java
devs too ;) )

9. Failures… a common property of distributed systems
Build a highly available system is difficult. In order for a system to be truly resilient,
fault-tolerance must be handled right from the start.
Systems will fail but they have to recover quickly.
Supervision is one of the fundamental concepts used by reactive applications in order
to be fault-tolerant.
A popular implementation of supervision can be found in actor programming model.

10. Let’s build a reactive app
Reactive Twitter

11. But first...
We need to talk about some useful topics to understand reactive apps on Play.
Scala and functional programming
Higher order functions
Immutable state
For comprehensions
Pattern matching
Immutable collections
Scala futures
Futures composition

12. Iteratees vs Reactive Streams
Iteratees is a Play construct that allows you to consume streams of data
asynchronously.
Enumerator is an asynchronous producer of data.
Enumeratee transforms pieces of streaming data from a type to another type on the
fly.
Asynchronous stream processing with nonblocking back pressure, becoming in a
new standard.
Publishers and subscribers of streaming data work in harmony. Subscribers
communicate with publishers to prevent the system getting overwhelmed.

13. Thank you!