A summary of Reactive topics. Mostly based on whitepaper: "Reactive Programming versus Reactive Systems Landing on a set of simple Reactive design principles in a sea of constant confusion and overloaded expectations". (By Jonas Bonér and Viktor Klang, Lightbend Inc)

1. Aleksey Izmailov
Jan 2019

2. § Reactive Programming is a distinct subset of Reactive Systems at the
implementation level.
§ Reactive Programming offers productivity for Developers—through
performance and resource efficiency—at the component level for internal
logic and dataflow management.
§ Reactive Systems offers productivity for Architects and DevOps—through
resilience and elasticity—at the system level, for building “Cloud Native” or
other large-scale distributed systems.

3. https://www.reactivemanifesto.org

4. Reactive
Systems
are …
Responsive
Responsive:
The system responds in a timely manner if at
all possible. Responsiveness is the cornerstone
of usability and utility, but more than that,
responsiveness means that problems may be
detected quickly and dealt with effectively.
Responsive systems focus on providing rapid
and consistent response times, establishing
reliable upper bounds so they deliver a
consistent quality of service. This consistent
behaviour in turn simplifies error handling,
builds end user confidence, and encourages
further interaction.

5. Reactive
Systems
are: …
Resilient
Resilient:
The system stays responsive in the face
of failure. This applies not only to highly-
available, mission-critical systems — any
system that is not resilient will be
unresponsive after a failure. Resilience is
achieved by replication,
containment, isolation and delegation. Failures
are contained within each component, isolating
components from each other and thereby
ensuring that parts of the system can fail and
recover without compromising the system as a
whole. Recovery of each component is
delegated to another (external) component and
high-availability is ensured by replication
where necessary. The client of a component is
not burdened with handling its failures.

6. Reactive
Systems
are …
Elastic
Elastic:
The system stays responsive under varying
workload. Reactive Systems can react to
changes in the input rate by increasing or
decreasing the resources allocated to service
these inputs. This implies designs that have no
contention points or central bottlenecks,
resulting in the ability to shard or replicate
components and distribute inputs among
them. Reactive Systems support predictive, as
well as Reactive, scaling algorithms by
providing relevant live performance measures.
They achieve elasticity in a cost-effective way
on commodity hardware and software
platforms.

7. Reactive
Systems
are …
Message
Driven
Message Driven:
Reactive Systems rely on asynchronous message-
passing to establish a boundary between
components that ensures loose coupling,
isolation and location transparency. This
boundary also provides the means to
delegate failures as messages. Employing explicit
message-passing enables load management,
elasticity, and flow control by shaping and
monitoring the message queues in the system
and applying back-pressure when necessary.
Location transparent messaging as a means of
communication makes it possible for the
management of failure to work with the same
constructs and semantics across a cluster or
within a single host. Non-
blocking communication allows recipients to only
consume resources while active, leading to less
system overhead.

8. Idea?! It is time to apply these design principles
consciously from the start instead of
rediscovering them each time.

9. Asynchrony, in computer programming, refers to the occurrence of events
independent of the main program flow and ways to deal with such events.
These may be "outside" events such as the arrival of signals, or actions
instigated by a program that take place concurrently with program execution,
without the program blocking to wait for results.

11. import requests
r = requests.get('https://api.github.com’)
f = open(“workfile”,”r”)
predict(
x,
batch_size=None,
verbose=0,
steps=None,
max_queue_size=10,
workers=1,
use_multiprocessing=False
)
def create_connection(db_file):
try:
conn = sqlite3.connect(db_file)
return conn
except Error as e:
print(e)
return None
def select_all_tasks(conn):
cur = conn.cursor()
cur.execute("SELECT * FROM tasks")
rows = cur.fetchall()
for row in rows:
print(row)

12. The Application Program Interface (API) for Reactive Programming libraries are
generally either:
§ Callback-based—where anonymous, side-effecting callbacks are attached to
event sources, and are being invoked when events pass through the dataflow
chain.
§ Declarative—through functional composition, usually using well established
combinators like map, filter, fold etc.

13. § Futures/Promises—containers of a single value, many-read/single-write
semantics where asynchronous transformations of the value can be added
even if it is not yet available.
§ Streams—as in Reactive Streams: unbounded flows of data processing,
enabling asynchronous, non-blocking, back-pressured transformation
pipelines between a multitude of sources and destinations.
§ Dataflow Variables—single assignment variables (memory-cells) which can
depend on input, procedures and other cells, so that changes are
automatically updated. A practical example is spreadsheets—where the
change of the value in a cell ripples through all dependent functions,
producing new values “downstream.”

23. Messages have a clear, single, destination;
while Events are facts for others to observe.
Event-driven system focuses on addressable event sources while a message-
driven system concentrates on addressable recipients.
In a Reactive System, especially one which uses Reactive Programming, both
events and messages will be present—as one is a great tool for
communication (messages), and another is a great way of representing
facts (events).

24. The foundation for a Reactive System is Message-Passing, which creates a
temporal boundary between components which allows them to be decoupled
in:
§ time—this allows for concurrency
§ space—which allows for distribution and mobility.
This decoupling is a requirement for full isolation between components, and
forms the basis for both Resilience and Elasticity.

25. Reactive Programming is a great technique for managing internal logic and
dataflow transformation, locally within the components, as a way of optimizing
code clarity, performance and resource efficiency.
Reactive Systems, being a set of architectural principles, puts the emphasis on
distributed communication and gives us tools to tackle resilience and elasticity
in distributed systems.

26. § Reactive Programming is used within a single Microservice to implement the
service-internal logic and dataflow management.
§ Reactive Systems design is used in between the Microservices, allowing the
creation of systems of Microservices that play by the rules of distributed
systems—Responsiveness through Resilience and Elasticity made possible by
being Message-Driven.

28. § Reactive Programming versus Reactive Systems. Landing on a set of simple
Reactive design principles in a sea of constant confusion and overloaded
expectations By Jonas Bonér and Viktor Klang, Lightbend Inc. – Most of the
text and pictures are copied from this resource.
§ Concurrency: The Good, The Bad and The Ugly. By Viktor Klang and Roland
Kuhn (https://www.youtube.com/watch?v=OJfS7K-Vkgk).
§ Wikipedia.
§ Scala and Akka documentation.
§ Some images are taken from public Internet.