What is Reactive programming?

What is Reactive Programming?An Overview of the Reactive Programming Paradigm

A Pre-Reactive World.

–Dan Kegel: The C10k Problem, 1999

“It’s time for web servers to handle ten thousand clients simultaneously.”

Expectations in the year 2000

4

• Limited connectivity


5


• Snapshots of data on hard drives,

centralized databases, etc


6




• Response times in seconds


7




• Response times in seconds

• Downtime all the time

Hardware in the year 2000

8

• A single machine with a single core


9


• Limited networking — e.g, a mix of broadband, dialup internet, FidoNet


10



• Expensive memory, CPU, hard drives


11



• Expensive memory, CPU, hard drives

• Small data

–Dan Kegel: The C10k Problem, 1999

“In 1999, one of the busiest FTP sites, cdrom.com, handled 10,000 clients simultaneously through a Gigabit Ethernet pipe.”

Fast forward 14 years.

Expectations have changed. Hardware has changed.


15

• Limited connectivity ⇨ always connected


16


• Snapshots of small data ⇨ real-time streams, distributed big data


17



• Response times in seconds ⇨ response times in milli/microseconds


18



• Response times in seconds ⇨ response times in milli/microseconds

• Downtime all the time ⇨ downtime measured in seconds


19

• A single machine ⇨ clusters of machines


20


• A single core ⇨ multiple cores


21



• Slow networks ⇨ fast networks


22



• Slow networks ⇨ fast networks

• Small data snapshots ⇨ big data streams

–Scott Andreas, Urban Airship

“If one node can only serve 10,000 clients, the venture is cost-prohibitive from the start – just one million devices would require a fleet of 100

servers.”

In 2010, Urban Airship used Java NIO to successfully test 512,000+ concurrent connections on a single 2.5 GB EC2 instance.

Realities of modern software development

25

• Applications are distributed by default


26


• Applications are composed from other applications


27



• Performance expectations — a slow application is a dead application


28




• UIs must adapt to multiple screen sizes and types of input


29




• UIs must adapt to multiple screen sizes and types of input

• Developers can no longer avoid parallelism and concurrency

C10k ⇨ C500k

Not so fast…

–Mihai Rotaru, 2013, discussing MigratoryData WebSocket server

“MigratoryData scales up to 12 million concurrent users from a single Dell PowerEdge R610 server while pushing up to 1.015 Gbps live data

(each user receives a 512-byte message every minute).”

C10k ⇨ C12m

What is Reactive Programming?

–Jonas Bonér

“Instead of the latest framework of the day or the latest buzzword, reactive brings the talk back to core principles; the design, the

architecture, the way we think about building software.”

Core principles of reactive software

36

• React to events ⇨ Event-driven

• React to load ⇨ Scalable

• React to failure ⇨ Resilient

• React to users ⇨ Responsive

• Reactive ⇨ Event-driven, Scalable, Resilient, Responsive

Reactive

37

re·spon·sive !

“Reacting quickly and positively.” !

synonyms: quick to react to, reactive to, receptive to, open to suggestions about, amenable to, flexible to, sensitive to, sympathetic to

Responsive — flexibility

39

Progressive UI enhancement

• Never allow slow external dependencies to degrade the user experience

Blue skies

• Never assume blue skies, assume grey skies

Responsive — quick to react

40

Beware of blocking IO!

• Asynchronous — non-blocking, blocking

• Synchronous — non-blocking, blocking

• Do you know what type your web framework implements?

Perceived quality • Perception of responsiveness is key, feel counts!

• Never, ever perform blocking IO on the UI thread!

Responsiveness !

Being quick to react to all users of a system — under blue skies and grey skies — in order to ensure a consistent experience.

scal·able !

“Capable of being easily expanded or upgraded on demand.” !

synonyms: ascendable, climbable, extensible, expandable, expansible, adaptable, elastic, flexible

Scalable

43

Important terms • Performance — a measure of your response time

• Load — impacts performance if not handled properly

Dealing with load • Scale up — faster CPU, more memory, bigger hard drive

• Scale out — distribute work across nodes and clusters

Scalability !

The capability of your system to be easily upgraded on demand in order to ensure responsiveness under various load conditions.

re·sil·ient !

“Able to withstand or recover quickly from difficult conditions.” !

synonyms: strong, tough, hardy

Resilient

46

Bulkheads • Partitioning — partition thread groups for different functionality

Backpressure • Throttling — wait for a consumer to demand more work

Circuit Breakers • Stability — Failing external dependencies shouldn’t bring down an entire app

Resiliency !

The proper application of fundamental design and architecture principles to ensure responsiveness under grey skies.

e·vent !

“Something that happens or is regarded as happening; an occurrence, especially one of some importance.”

!

driv·en !

“Propelled or motivated by something.”

Traditional concurrency models

49

Thread based concurrency with objects and shared state • Imperative, sequential execution

• Most common programming paradigm

• Threads for concurrency

• Difficult to reason about, error-prone

• Implementations — most OO based web frameworks, languages, and toolkits

Traditional concurrency models

50

Software transactional memory (STM) • Immutable values

• Atomicity, consistency, isolation and durability

• Cannot perform any operation that cannot be undone, including (most) I/O

• Think command pattern/interface

• Implementations — Haskell STM (native), libs for Scala, Java, OCaml, Clojure, etc

Share nothing concurrency

51

Event driven concurrency • Thread based event loops

• Often single threaded

• Implementations — Node.js, Twisted Python, EventMachine (Ruby)

Share nothing concurrency

52

Actor based concurrency • Mutable state, but completely isolated

• State only mutated by the actor

• Asynchronous message passing between actors using mailboxes

• Thread based actors or event based actors

• Implementations — Erlang, Akka

Event driven !

An event driven architecture forces programmers to deal with scalability and resilience at a code level in order to facilitate responsiveness.

re·ac·tive !

“Responsive to stimulus.” !

synonyms: active, aware, conscious, receptive, sensitive, acknowledging, alive, answering

Reactive

55

A quick code example.

–@davidlohr

A programmer had a problem. They thought to themselves, "I know, I'll solve it with threads". have Now problems two they.

Non-deterministic — mutable state, threads, locks

58

var a = foo.getB() + bar.getC()!System.out.println(a) // “42”!a = foo.getB() + bar.getC()!System.out.println(a) // Who knows?

Non-deterministic — mutable state, threads, locks

59

var a = foo.getB() + bar.getC()!System.out.println(a) // “42”!a = foo.getB() + bar.getC()!System.out.println(a) // Who knows?!!

• The value of a may or may not still be 42

• Is another thread is mutating foo or bar?

• Pull-based — getB() and getC() must be explicitly invoked

• Later mutation to foo and bar doesn’t effect a

• Based on time and space

Why is non-determinism the root of all evil?

60

Key terms • Parallelism — when at least two threads are executing simultaneously

• Concurrency — when at least two threads are making progress

Mutable state + threads + locks • Code that is error prone and difficult to reason about

• Extremely difficult to implement parallelism and concurrency with MuSTL

Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM.

A simple Akka code example

62

class GameActor extends Actor {! def receive = {! case handshakeRequest: HandshakeRequest => ! sender ! computeHandshakeResponse(handshakeRequest)! case turnMessage: TurnMessage => ! sender ! computeTurnResponse(turnMessage) ! }!}!!

• Time, space, mutation ⇨ flow, events, messages

Akka Actors

63

• Process messages asynchronously

• Pattern match against message types

• Focus on flow and values — not objects, threads, and locks

• Higher-level of abstraction — easier to write concurrent, distributed systems

• Think observable/observer and pub/sub

• Influenced by the Erlang actor model

Erlang has embraced the tenets of reactive programming since 1985.

Erlang characteristics and use cases

65

• Share nothing architecture — processes cannot share data

• Pure message passing — copy all the data you need in the messages

• Crash detection and recovery — things will crash, so let them crash then recover

Erlang characteristics and use cases

66

Popular Erlang Software • Wings 3D — 3D modelling • Ejabberd — instant messaging server • CouchDB — document database • RabbitMQ — enterprise-y messaging

Erlang in Production • Ericsson — 3G mobile networks

• Amazon — SimpleDB, EC2

• Facebook — back-end chat server

• T-Mobile — SMS and authentication

–Jonas Bonér

“Reactive looks back in history. It doesn't ignore the goldmine of knowledge that's been around for 30 to 40 years, but rather tries to bring

it into new context.”

Sources and credits

68

• Jonas Bonér — Reactive Supply to Changing Demand

• Joe Armstrong — K things I know about building Resilient Reactive Systems

• Benjamin Erb — Concurrent Programming for Scalable Web Architectures

• Rich Hickey — The Value of Values

• Plus various talks, papers, books, blog posts, and tweets by…

• Dean Wampler, Erik Meijer, Martin Odersky, Martin Thompson, etc

©Typesafe 2014 – All Rights Reserved