Reactive Web Architectures

Slide 1

Slide 1 text

Reactive Web Architectures Dynatrace Brown-Bag Session 24.09.2020

Slide 2

Slide 2 text

David Leitner Coding Architect david.leitner@squer.at duffleit

Slide 3

Slide 3 text

reactive programming with, or designing upon, asynchronous data streams.

Slide 4

Slide 4 text

Space Time Collections Iterator Generator Value Getter Setter Promise Deferred Resolver Stream Reader Emitter

Slide 5

Slide 5 text

The relationship between them is implicit, an idea that only exists in the mind of the programmers. It should be explicit, a part of the language, and existing for all time. Counter and Double should be bound. = the Destiny Operator

Slide 6

Slide 6 text

Stream Caller Receiver Caller Receiver propagate change observe change trigger change directly The reactive programming paradigm is based on asynchronous streams which propagate change. This differs from imperative programming, where statements are used to change a program’s state.

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

UserImage . Username Click Stream User Data Stream Error Stream Error Panel observes observes Http Service

Slide 9

Slide 9 text

IS THE NEW

Slide 10

Slide 10 text

The Reactive Manifesto Message Driven Responsive Elastic Resilient Value Form Means Maintainability Extendibility

Slide 11

Slide 11 text

Microservice A Microservice B Message Driven Responsive Elastic Resilient Value Form Means

Slide 12

Slide 12 text

Microservice A Microservice B Message Driven Responsive Elastic Resilient Value Form Means Microservice B

Slide 13

Slide 13 text

Microservice A Microservice B Message Driven Responsive Elastic Resilient Value Form Means Microservice B Stream

Slide 14

Slide 14 text

Microservice A Microservice B Message Driven Responsive Elastic Resilient Value Form Means

Slide 15

Slide 15 text

Message Driven Responsive Elastic Resilient Value Form Means Microservice A Stream Microservice B

Slide 16

Slide 16 text

We support Back-Pressure Stream Provider Consumer events are stored until consumed Stream Provider Consumer A Consumer C Consumer B scaling out consumers We can scale-out by Location Transparency

Slide 17

Slide 17 text

We move from a pull-based design, to an asynchronous push-based design.

Slide 18

Slide 18 text

GraphQL Consumer Driven APIs Native Schema Support Streaming Support

Slide 19

Slide 19 text

Microservice A Microservice B Microservice C Web Application Stream Stream

Slide 20

Slide 20 text

Microservice A Microservice B Microservice C Web Application Stream BFF HTTP Mobile App BFF Hydration

Slide 21

Slide 21 text

Lambda A Lambda B Lambda C Client Event Stream BFF Hydration Stateful 3 Factor Architecture Factor #1: Realtime GraphQL Factor #2: Reliable eventing Factor #3: Async serverless

Slide 22

Slide 22 text

This stuff is cool, but think twice (!) if reactive architectures really fit your problem at hand.