O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Next generation of frontend architectures

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 44 Anúncio

Next generation of frontend architectures

Baixar para ler offline

Introduction to CSP and Reactive Programming with RxJS.
This is the link of the talk related to this slides made for O'Reilly Media: http://www.oreilly.com/pub/e/3634?registered=yes

Introduction to CSP and Reactive Programming with RxJS.
This is the link of the talk related to this slides made for O'Reilly Media: http://www.oreilly.com/pub/e/3634?registered=yes

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Quem viu também gostou (11)

Semelhante a Next generation of frontend architectures (20)

Anúncio

Mais recentes (20)

Anúncio

Next generation of frontend architectures

  1. 1. Next generation of FRONT END architectures
  2. 2. HELLO! I am Luca Mezzalira Solutions Architect @ Massive Interactive Community Manager of London JavaScript User Group
  3. 3. AGENDA ▸ Front end architectures overview ▸ Communicating sequential processes ▸ Transducers ▸ Functional Reactive programming
  4. 4. 1. ARCHITECTURES PAST & PRESENT
  5. 5. Architectures Timeline 90s MVP 80s MVC 2005 MVVM 2013 FLUX 2009 DCI 2015 MVI
  6. 6. ▸ SOLID principles ▸ Encapsulation ▸ Loose coupled ▸ High scalability ▸ Event driven ▸ ... COMMONALITY
  7. 7. Which is one of the main challenge working with event driven architectures?
  8. 8. ▸ Events ▸ Signals ▸ Pub/Sub system ▸ Actions + Dispatcher ▸ Commands ▸ ... OBJECTS COMMUNICATION
  9. 9. 2. COMMUNICATING SEQUENTIAL PROCESSES
  10. 10. “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
  11. 11. 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
  12. 12. CHANNEL INJECTION VIEW controller or presentation model or model or intent CHANNEL
  13. 13. 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
  14. 14. 3. TRANSDUCERS
  15. 15. “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.
  16. 16. TRANSDUCERS TRANSFORM: producing some value from another REDUCER: combining values of a data structure to produce a new one
  17. 17. TRANSFORMATION IN MVC, MVP, MVVM presentation model or view-model model
  18. 18. TRANSFORMATION WITH TRANSDUCERS VIEW MODEL or PRESENTATI ON MODEL CHANNEL with TRANSDUCER
  19. 19. 4. FUNCTIONAL REACTIVE PROGRAMMING
  20. 20. 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.
  21. 21. WHY IS REACTIVE PROGRAMMING SO INTERESTING?
  22. 22. “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
  23. 23. . RESPONSIVE . ELASTIC . RESILIENT . MESSAGE DRIVEN RESPONSIVE MESSAGE DRIVEN RESILIENTELASTIC
  24. 24. REACTIVE PROGRAMMING IS PROGRAMMING WITH ASYNCHRONOUS DATA STREAMS
  25. 25. 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.
  26. 26. 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
  27. 27. RxJS
  28. 28. “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...
  29. 29. 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
  30. 30. 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.
  31. 31. 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.
  32. 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. 33. MARBLES DIAGRAM rxmarbles.com
  34. 34. 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
  35. 35. CSP vs RxJS
  36. 36. VIEW INTENT MODEL RENDERER futurice.com/blog/reactive-mvc-and-the-virtual-dom
  37. 37. 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
  38. 38. 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
  39. 39. INTENT Input: raw user input events from the View. Output: model-friendly user intention events. INTENT
  40. 40. MODEL Input: user interaction events from the Intent. Output: data events. MODEL
  41. 41. 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
  42. 42. Cycle.js
  43. 43. Can I use CSP and/or Reactive Programming in any project?
  44. 44. THANKS EVERYONE Q&A @lucamezzalira www.lucamezzalira.com www.londonjs.uk mezzalab@gmail.com

×