Next generation of frontend architectures

44
Next generation of FRONT END architectures

Transcript of Next generation of frontend architectures

Page 1: Next generation of frontend architectures

Next generation of FRONT END architectures

Page 2: Next generation of frontend architectures

HELLO!

I am Luca MezzaliraSolutions Architect @ Massive Interactive

Community Manager of London JavaScript User Group

Page 3: Next generation of frontend architectures

AGENDA▸ Front end architectures

overview

▸ Communicating sequential processes

▸ Transducers

▸ Functional Reactive programming

Page 4: Next generation of frontend architectures

1.ARCHITECTURES PAST & PRESENT

Page 5: Next generation of frontend architectures

Architectures Timeline

90s

MVP

80s

MVC

2005

MVVM

2013

FLUX

2009

DCI

2015

MVI

Page 6: Next generation of frontend architectures

▸ SOLID principles▸ Encapsulation▸ Loose coupled▸ High scalability▸ Event driven▸ ...

COMMONALITY

Page 7: Next generation of frontend architectures

Which is one of the main challenge working with event driven architectures?

Page 8: Next generation of frontend architectures

▸ Events▸ Signals▸ Pub/Sub system▸ Actions + Dispatcher▸ Commands▸ ...

OBJECTS COMMUNICATION

Page 9: Next generation of frontend architectures

2.COMMUNICATINGSEQUENTIAL PROCESSES

Page 10: Next generation of frontend architectures

“CSPCSP 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

Page 11: Next generation of frontend architectures

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

Page 12: Next generation of frontend architectures

CHANNEL INJECTION

VIEW

controller or presentation

model or model or

intent

CHANNEL

Page 13: Next generation of frontend architectures

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

Page 14: Next generation of frontend architectures

3.TRANSDUCERS

Page 15: Next generation of frontend architectures

“TRANSDUCERSTransducers 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.

Page 16: Next generation of frontend architectures

TRANSDUCERSTRANSFORM: producing some value from another

REDUCER: combining values of a data structure to produce a new one

Page 17: Next generation of frontend architectures

TRANSFORMATION IN MVC, MVP, MVVM

presentation model orview-model

model

Page 18: Next generation of frontend architectures

TRANSFORMATION WITH TRANSDUCERS

VIEWMODEL or

PRESENTATION MODEL

CHANNEL with

TRANSDUCER

Page 19: Next generation of frontend architectures

4.FUNCTIONAL REACTIVE PROGRAMMING

Page 20: Next generation of frontend architectures

PROGRAMMING PARADIGMSFUNCTIONALIt 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.

IMPERATIVEIt 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 REACTIVEIt 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.

Page 21: Next generation of frontend architectures

WHY ISREACTIVE PROGRAMMING SO INTERESTING?

Page 22: Next generation of frontend architectures

“REACTIVE MANIFESTOWe 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

Page 23: Next generation of frontend architectures

. RESPONSIVE

. ELASTIC

. RESILIENT

. MESSAGE DRIVEN

RESPONSIVE

MESSAGE DRIVEN

RESILIENTELASTIC

Page 24: Next generation of frontend architectures

REACTIVE PROGRAMMING IS PROGRAMMING WITH ASYNCHRONOUS DATA STREAMS

Page 25: Next generation of frontend architectures

OBSERVER PATTERNThe 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.

Page 26: Next generation of frontend architectures

ITERATOR PATTERNIn 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

Page 27: Next generation of frontend architectures

RxJS

Page 28: Next generation of frontend architectures

“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...

Page 29: Next generation of frontend architectures

STREAMSA 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

Page 30: Next generation of frontend architectures

COLD OBSERVABLESCold 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.

Page 31: Next generation of frontend architectures

HOT OBSERVABLESWhen 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.

Page 32: Next generation of frontend architectures

OPERATORS▸ Creating Observables▸ Transforming Observables ▸ Filtering Observables▸ Combining Observables▸ Error Handling Operators▸ Mathematical Operators▸ Conditional Operators▸ Connectable Observables

Operators

reactivex.io/documentation/operators.html

Page 33: Next generation of frontend architectures

MARBLES DIAGRAM

rxmarbles.com

Page 34: Next generation of frontend architectures

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

Page 35: Next generation of frontend architectures

CSP vs RxJS

Page 36: Next generation of frontend architectures

VIEW INTENT

MODEL

RENDERER

futurice.com/blog/reactive-mvc-and-the-virtual-dom

Page 37: Next generation of frontend architectures

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

Page 38: Next generation of frontend architectures

VIEWInput: 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

Page 39: Next generation of frontend architectures

INTENTInput: raw user input events from the View.

Output: model-friendly user intention events.

INTENT

Page 40: Next generation of frontend architectures

MODELInput: user interaction events from the Intent.

Output: data events.

MODEL

Page 41: Next generation of frontend architectures

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

Page 42: Next generation of frontend architectures

Cycle.js

Page 43: Next generation of frontend architectures

Can I use CSP and/orReactive Programmingin any project?

Page 44: Next generation of frontend architectures

THANKS EVERYONE

Q&A@lucamezzalira

www.lucamezzalira.com

www.londonjs.uk

[email protected]