From Reactive Systems to Reactive Programming
A journey in Reactive world, explaining differences between various meanings of word “Reactive” … in order to better understand this new and interesting both architectural and development approach.
whoami
A Software Architect with over 25 years of experience.
CTO in Softphone and Cofounder of SoulSofware company.
an active contributor to the open source eco-system. https://github.com/bsorrentino
http://soulsoftware-bsc.blogspot.it/
https://twitter.com/bsorrentinoJ
https://www.linkedin.com/in/bartolomeosorrentino
Reactive
We would introduce the following Reactive concepts and different application of Reactive word
-
Reactive System
-
Reactive Service & Application
-
Reactive Execution Environment
-
Reactive Programming
briefly overview of
The Reactive Manifesto
Published in 2014 the Reactive manifesto refers to Reactive System as system that are more flexible, loosely-coupled and scalable.
Such system must be:
- Responsive
- Resilient
- Elastic
- Message Driven
Reactive Manifesto - Reactive System
The Reactive Manifesto introduces a
"tech. agnostic shared vocabulary"
that will help us to better understand the concepts that we will meet during our knowledge acquisition path:
The main terms are:
- Asynchronous
- Non-Blocking
- Back-Pressure
- Delegate Errors
Reactive Manifesto Vocabulary
Key Questions
Are reactive systems and reactive programming the same thing?
No, they are not!
Though often used interchangeably, the terms are not exactly synonymous and reflect different things.
Do we need
reactive programming to build a reactive system?
No, we don't!
To build a Reactive system it is not mandatory switching to reactive programming, even if using it will help you to fully apply the reactive nature of your system.
To build a reactive system all the parts composing it must to be reactive ?
the answer is .. DEPENDS!
Typically reactivity can be smoothly introduced depending on the Use Cases that we are analysing.
We could consider reactive also a system that partially apply reactive patterns
To build a reactive service we must rely on a reactive middleware and programming ?
the answer is .. Not necessarily!
Service must behave reactively i.e. be able to handle and react to incoming messages, but It is not forced to rely on particular reactive middleware or need to be implemented using reactive programming
(i.e. internally service logic could be performed in synchronous way )
A service relying exclusively on RESTful api could be considered reactive ?
the answer is .. generally No!
RESTFul api are commonly used to enforce synchronous flow, but a service that accepts command through REST call and return results through events is definitely a reactive service.
(Main strategy on which db services are focusing to become reactive)
What are the system typologies that better fits reactive approach ?
Going reactive provides a solution when it comes to specific types of high-load or multi-user systems like:
- Social networks, chats
- Games
- Audio and video apps
- Server code that serves highly interactive UI elements
- Proxy servers, load balancers
- Artificial intelligence, machine learning
- Real-time data streaming
Key Concepts
Reactive systems represent the higher level of ‘reactivity’.
This level implies specific design and architectural decisions that allow building resilient, flexible, and responsive applications.
Essentially a Reactive System is a Message Driven Distributed System on which will be applied architectural patterns and used tools to enforce elasticity and resiliency
To simplify we can collapse all concepts in one meaningful sentence:
Reactive System
A reactive system is a distributed system designed upon asynchronous data flows
Reactive Service
(aka Component)
When we speak about a distributed system we image a bunch of services & applications interconnected between them.
We can define a Reactive Service a service that :
- Enforces asynchronous communication (async-data-flow)
- Avoid to share mutable state (share-nothing-architecture)
Services we mean the Business Services belonging to back-end architecture
Applications we mean the Consumer Apps belonging to front-end architecture
Reactive Execution Environment
(aka Reactive Runtime)
Another Reactive aspect that often is confused and/or mixed with reactive system one, is the reactive execution environment or more in general a reactive runtime.
This concerns how/what a process can help/provide an/to application or service to be as much reactive as possible
(i.e. responsive, elastic, resilient)
Reactive Execution Environment
(rise of asynchronous)
This is one of the most discussed aspect of reactive world because differently from the past seems that to achieve reactiveness (faster, better, cheaper) we don’t need to deal with concurrency and multi threads anymore but with asynchronicity and immutability.
Reactive Execution Environment
(rise of multi-core )
The One-Thread-Per-Request Model was designed when single-core CPUs were the norm and with rise of multi-core processors the best way to use them is to reduce the "IO Waiting" and here comes into play reactive asynchronous model (& programming)
Reactive Execution Environment
(MessageLoop & non-blocking I/O)
Basic idea behind reactive runtime is to create an internal event driven architecture based on few of threads managing messages loop and non-blocking I/O that completely (as much as possible) hides concurrency and threads management in favor of asynchronicity and immutability.
Multi threads != Asynchronous
Less stressed threads work better that many lazy threads
Reactive Execution Environment
(Native vs Middleware)
Currently there are available several reactive runtime, some are purely native reactive implementation others are middleware/framework that extend/adapt existent ones
Native
- Internet browser
- Nodejs
Adapted (JVM)
- Akka/Play
- Vertx+netty
- springboot+webflux+netty
Reactive Execution Environment
(unveiled)
Reactive Programming
- Reactive Programming is a synonym of Functional Reactive Programming (FRP)
- Each reactive runtime provides one (more) framework(s) allowing to deal with it.
- Reactive programming is a totally different approach towards writing code.
- Everything in a reactive world is considered a stream.
- These streams are immutable and there are a plethora of operators available that operate on these streams.
- The real power of reactive programming lies in these tried and tested operators.
What do I get with FRP in real life
- Increased performance – due to the possibility to handle huge volumes of data in a quick and stable way.
- Improved UX – due to the possibility to keep the application more responsive to its user.
- Simplified modifications and updates – due to more readable and easier to predict code.
1) Fluently
(use Builder Pattern)
2) Fluently + Functional
(use and abuse of lamdba)
3) Fluently + Functional + Asynchronous
(use MessageLoop and Scheduler)
Path toward FRP
Start to develop
Design Patterns
Here the famous design patterns that everyone known.
but not always everyone apply
Reactive Distillate
Design Patterns
Here the only patterns need to be reactive:
Iterator:
To iterate over data in one way
Observer:
To handle and process data
Builder:
To achieve fluently and expressive code
I have a Stream
Observable Async. Data Stream
The Marble Diagram
A great way to represent stream processing
From Sequence to Marble Diagrams
Operators
The Core of the RX that enable stream processing through function composition
You have to know how properly applying them to achieve the powerful of RX
Operators' Land
Which operator to use ?
Develop using Reactive Programming
The Reactive Extension
RX
RX: where is supported it
