Thanks to visit codestin.com
Credit goes to www.slideshare.net

Next generation
of FRONT END
architectures
HELLO!
I am Luca Mezzalira
Solutions Architect @ Massive Interactive
Community Manager of London JavaScript User Group
AGENDA
▸ Front end architectures
overview
▸ Communicating
sequential processes
▸ Transducers
▸ Functional Reactive
programming
1.
ARCHITECTURES
PAST & PRESENT
Architectures Timeline
90s
MVP
80s
MVC
2005
MVVM
2013
FLUX
2009
DCI
2015
MVI
▸ SOLID principles
▸ Encapsulation
▸ Loose coupled
▸ High scalability
▸ Event driven
▸ ...
COMMONALITY
Which is one of the main challenge
working with event driven
architectures?
▸ Events
▸ Signals
▸ Pub/Sub system
▸ Actions + Dispatcher
▸ Commands
▸ ...
OBJECTS COMMUNICATION
2.
COMMUNICATING
SEQUENTIAL
PROCESSES
“CSP
CSP allows the description of systems in terms of
component processes that operate
independently, and interact with each other
solely through message-passing communication.
However, the "Sequential" part of the CSP name is
now something of a misnomer, since modern CSP
allows component processes to be defined both
as sequential processes, and as the parallel
composition of more primitive processes
CSP
▸ Created in 1978
▸ CSP-js porting from Clojure
(core.async) and GO
▸ Composition over
Inheritance
▸ Easier to test
▸ Loose coupled
▸ Well encapsulated
▸ Clean and reusable code
CHANNEL
INJECTION
VIEW
controller or
presentation
model or
model or
intent
CHANNEL
CSP APIs
▸ set a buffer inside a channel
▸ put and take value from a channel
▸ close a channel
▸ close a channel after N ms
▸ put the array values inside a channel
▸ return a channel with the values inside an array
▸ split, merge or pipe channels
▸ pub/sub system (observer pattern)
▸ broadcast values to multiple channels simultaneously
▸ map, filter, remove data from a channel
▸ avoid duplicated data inside a channel
▸ decorate data inside a channel
3.
TRANSDUCERS
“TRANSDUCERS
Transducers are composable algorithmic
transformations.
They are independent from the context of their input
and output sources and specify only the essence of the
transformation in terms of an individual element.
Because transducers are decoupled from input or output
sources, they can be used in many different processes -
collections, streams, channels, observables, etc.
TRANSDUCERS
TRANSFORM: producing some
value from another
REDUCER: combining values of
a data structure to produce a
new one
TRANSFORMATION
IN MVC, MVP, MVVM
presentation
model or
view-model
model
TRANSFORMATION
WITH
TRANSDUCERS
VIEW
MODEL or
PRESENTATI
ON MODEL
CHANNEL
with
TRANSDUCER
4.
FUNCTIONAL
REACTIVE
PROGRAMMING
PROGRAMMING PARADIGMS
FUNCTIONAL
It is a declarative
programming paradigm,
which means
programming is done
with expressions. In
functional code, the
output value of a
function depends only
on the arguments that
are input to the
function, so calling a
function f twice with the
same value for an
argument x will produce
the same result f(x)
each time.
IMPERATIVE
It is a programming
paradigm that uses
statements that change a
program's state. In much
the same way that the
imperative mood in
natural languages
expresses commands, an
imperative program
consists of commands
for the computer to
perform. Imperative
programming focuses
on describing how a
program operates.
FUNCTIONAL
REACTIVE
It is a programming
paradigm oriented
around data flows and
the propagation of
change. This means that
it should be possible to
express static or dynamic
data flows with ease in
the programming
languages used, and that
the underlying execution
model will automatically
propagate changes
through the data flow.
WHY IS
REACTIVE
PROGRAMMING
SO INTERESTING?
“REACTIVE MANIFESTO
We believe that a coherent approach to systems
architecture is needed, and we believe that all necessary
aspects are already recognised individually: we want
systems that are Responsive, Resilient, Elastic and
Message Driven. We call these Reactive Systems.
Systems built as Reactive Systems are more flexible,
loosely-coupled and scalable. This makes them easier to
develop and amenable to change. [...] Reactive Systems
are highly responsive, giving users effective interactive
feedback.
www.reactivemanifesto.org
. RESPONSIVE
. ELASTIC
. RESILIENT
. MESSAGE DRIVEN
RESPONSIVE
MESSAGE DRIVEN
RESILIENTELASTIC
REACTIVE PROGRAMMING IS
PROGRAMMING WITH
ASYNCHRONOUS DATA STREAMS
OBSERVER PATTERN
The observer pattern is a software design pattern in which an object,
called the subject, maintains a list of its dependents, called
observers, and notifies them automatically of any state changes,
usually by calling one of their methods. It is mainly used to implement
distributed event handling systems.
ITERATOR PATTERN
In object-oriented programming, the iterator pattern is a design
pattern in which an iterator is used to traverse a container and
access the container's elements. The iterator pattern decouples
algorithms from containers
RxJS
“BACK-PRESSURE? WHAT?!
Main obstacle when you approach for the first time
Reactive Programming is the vocabulary.
My first suggestion is to familiarise with the domain, a lot
of concepts become way easier if you understand what
they mean before you start to work with them.
streams, hot observables, cold observables, marbles
diagram, back-pressure, operators...
STREAMS
A stream is a sequence of ongoing events
ordered in time. It can emit three different
things: a value (of some type), an error, or a
"completed" signal.
EVERYTHING CAN BE A STREAM
COLD OBSERVABLES
Cold observables start running upon
subscription: the observable sequence only starts
pushing values to the observers when subscribe
is called.
Values are also not shared among subscribers.
HOT OBSERVABLES
When an observer subscribes to a hot observable
sequence, it will get all values in the stream
that are emitted after it subscribes.
The hot observable sequence is shared among
all subscribers, and each subscriber is pushed
the next value in the sequence.
OPERATORS
▸ Creating Observables
▸ Transforming Observables
▸ Filtering Observables
▸ Combining Observables
▸ Error Handling Operators
▸ Mathematical Operators
▸ Conditional Operators
▸ Connectable Observables
Operators
reactivex.io/documentation/operators.html
MARBLES DIAGRAM
rxmarbles.com
TESTING
OBSERVABLES
▸ Create hot observables
▸ Create cold observables
▸ Create observer
▸ Simulate onNext, onError,
onComplete
▸ Create scheduler
▸ Basic assertion library
github.com/Reactive-
Extensions/RxJS/tree/master/doc
/api/testing
CSP vs RxJS
VIEW INTENT
MODEL
RENDERER
futurice.com/blog/reactive-mvc-and-the-virtual-dom
MVI RULES
▸ A module shouldn’t control
any other module (controller
in MVC)
▸ The only shared part between
modules is an observables
▸ Intent is a component with
only one responsibility: It
should interpret what the
user is trying to do in terms
of model updates, and export
these "user intentions" as
events
VIEW
Input: data events from the Model.
Output: a Virtual DOM rendering of the model,
and raw user input events (such as clicks,
keyboard typing, accelerometer events, etc).
VIEW
RENDERER
INTENT
Input: raw user input events from the View.
Output: model-friendly user intention events.
INTENT
MODEL
Input: user interaction events from the Intent.
Output: data events.
MODEL
MVI PROs
▸ Better separation of concern
▸ Monodirectional flow
▸ Dependency Injection
▸ Applications become easier
to test (in particular views)
▸ All the states live inside the
Model and the View is state-
agnostic
Cycle.js
Can I use CSP and/or
Reactive Programming
in any project?
THANKS EVERYONE
Q&A
@lucamezzalira
www.lucamezzalira.com
www.londonjs.uk
mezzalab@gmail.com

Next generation of frontend architectures

  • 1.
    Next generation of FRONTEND architectures
  • 2.
    HELLO! I am LucaMezzalira Solutions Architect @ Massive Interactive Community Manager of London JavaScript User Group
  • 3.
    AGENDA ▸ Front endarchitectures overview ▸ Communicating sequential processes ▸ Transducers ▸ Functional Reactive programming
  • 4.
  • 5.
  • 6.
    ▸ SOLID principles ▸Encapsulation ▸ Loose coupled ▸ High scalability ▸ Event driven ▸ ... COMMONALITY
  • 7.
    Which is oneof the main challenge working with event driven architectures?
  • 8.
    ▸ Events ▸ Signals ▸Pub/Sub system ▸ Actions + Dispatcher ▸ Commands ▸ ... OBJECTS COMMUNICATION
  • 9.
  • 10.
    “CSP CSP allows thedescription of systems in terms of component processes that operate independently, and interact with each other solely through message-passing communication. However, the "Sequential" part of the CSP name is now something of a misnomer, since modern CSP allows component processes to be defined both as sequential processes, and as the parallel composition of more primitive processes
  • 11.
    CSP ▸ Created in1978 ▸ CSP-js porting from Clojure (core.async) and GO ▸ Composition over Inheritance ▸ Easier to test ▸ Loose coupled ▸ Well encapsulated ▸ Clean and reusable code
  • 12.
  • 13.
    CSP APIs ▸ seta buffer inside a channel ▸ put and take value from a channel ▸ close a channel ▸ close a channel after N ms ▸ put the array values inside a channel ▸ return a channel with the values inside an array ▸ split, merge or pipe channels ▸ pub/sub system (observer pattern) ▸ broadcast values to multiple channels simultaneously ▸ map, filter, remove data from a channel ▸ avoid duplicated data inside a channel ▸ decorate data inside a channel
  • 14.
  • 15.
    “TRANSDUCERS Transducers are composablealgorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, they can be used in many different processes - collections, streams, channels, observables, etc.
  • 16.
    TRANSDUCERS TRANSFORM: producing some valuefrom another REDUCER: combining values of a data structure to produce a new one
  • 17.
    TRANSFORMATION IN MVC, MVP,MVVM presentation model or view-model model
  • 18.
  • 19.
  • 20.
    PROGRAMMING PARADIGMS FUNCTIONAL It isa declarative programming paradigm, which means programming is done with expressions. In functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time. IMPERATIVE It is a programming paradigm that uses statements that change a program's state. In much the same way that the imperative mood in natural languages expresses commands, an imperative program consists of commands for the computer to perform. Imperative programming focuses on describing how a program operates. FUNCTIONAL REACTIVE It is a programming paradigm oriented around data flows and the propagation of change. This means that it should be possible to express static or dynamic data flows with ease in the programming languages used, and that the underlying execution model will automatically propagate changes through the data flow.
  • 21.
  • 22.
    “REACTIVE MANIFESTO We believethat a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems. Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. [...] Reactive Systems are highly responsive, giving users effective interactive feedback. www.reactivemanifesto.org
  • 23.
    . RESPONSIVE . ELASTIC .RESILIENT . MESSAGE DRIVEN RESPONSIVE MESSAGE DRIVEN RESILIENTELASTIC
  • 24.
    REACTIVE PROGRAMMING IS PROGRAMMINGWITH ASYNCHRONOUS DATA STREAMS
  • 25.
    OBSERVER PATTERN The observerpattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
  • 26.
    ITERATOR PATTERN In object-orientedprogramming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements. The iterator pattern decouples algorithms from containers
  • 27.
  • 28.
    “BACK-PRESSURE? WHAT?! Main obstaclewhen you approach for the first time Reactive Programming is the vocabulary. My first suggestion is to familiarise with the domain, a lot of concepts become way easier if you understand what they mean before you start to work with them. streams, hot observables, cold observables, marbles diagram, back-pressure, operators...
  • 29.
    STREAMS A stream isa sequence of ongoing events ordered in time. It can emit three different things: a value (of some type), an error, or a "completed" signal. EVERYTHING CAN BE A STREAM
  • 30.
    COLD OBSERVABLES Cold observablesstart running upon subscription: the observable sequence only starts pushing values to the observers when subscribe is called. Values are also not shared among subscribers.
  • 31.
    HOT OBSERVABLES When anobserver subscribes to a hot observable sequence, it will get all values in the stream that are emitted after it subscribes. The hot observable sequence is shared among all subscribers, and each subscriber is pushed the next value in the sequence.
  • 32.
    OPERATORS ▸ Creating Observables ▸Transforming Observables ▸ Filtering Observables ▸ Combining Observables ▸ Error Handling Operators ▸ Mathematical Operators ▸ Conditional Operators ▸ Connectable Observables Operators reactivex.io/documentation/operators.html
  • 33.
  • 34.
    TESTING OBSERVABLES ▸ Create hotobservables ▸ Create cold observables ▸ Create observer ▸ Simulate onNext, onError, onComplete ▸ Create scheduler ▸ Basic assertion library github.com/Reactive- Extensions/RxJS/tree/master/doc /api/testing
  • 35.
  • 36.
  • 37.
    MVI RULES ▸ Amodule shouldn’t control any other module (controller in MVC) ▸ The only shared part between modules is an observables ▸ Intent is a component with only one responsibility: It should interpret what the user is trying to do in terms of model updates, and export these "user intentions" as events
  • 38.
    VIEW Input: data eventsfrom the Model. Output: a Virtual DOM rendering of the model, and raw user input events (such as clicks, keyboard typing, accelerometer events, etc). VIEW RENDERER
  • 39.
    INTENT Input: raw userinput events from the View. Output: model-friendly user intention events. INTENT
  • 40.
    MODEL Input: user interactionevents from the Intent. Output: data events. MODEL
  • 41.
    MVI PROs ▸ Betterseparation of concern ▸ Monodirectional flow ▸ Dependency Injection ▸ Applications become easier to test (in particular views) ▸ All the states live inside the Model and the View is state- agnostic
  • 42.
  • 43.
    Can I useCSP and/or Reactive Programming in any project?
  • 44.