What problems does reactive programming solve

Reactive programming

Transcript

1 Reactive programming Dino Omanovic tarent solutions GmbH domano S m fro! h c t a r c

2 tarent Solutions GmbH + Thanks for the support! + A lot of open source! 00. Compulsory Company Slide

3 That's what it's all about! REACTIVE? 01 OTHER LANGUAGES 02 GO IS DIFFERENT 03 BASICS 04 LIVE CODING 05 CONCLUSION 06

4 01 REACTIVE?

5 Reactive Systems VS Reactive Programming Often used together, not our topic 01. REACTIVE?

6 What is reactive programming? 01. REACTIVE?

7 Wikipedia In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

8 01 Code reacts to changes 01. REACTIVE?

9 reaction? + Each operation triggers an action + Example: Chat + Each input is distributed to all participants 01. REACTIVE?

10 02 Streams 01. REACTIVE?

11 streams? + A chain of events + operations are applied to the stream 01. REACTIVE?

12 03 Observer 01. REACTIVE?

13 Observer? + Has it been around for a long time + Changes will be communicated + Changes will be reacted to 01. REACTIVE?

14 02 OTHER LANGUAGES

15 ReactiveX, ReactiveX, ReactiveX OTHER LANGUAGES

16 RxJava public static void hello (string ... names) {Observable.from (names) .subscribe (new Action1 () public void call (string s) {System.out.println ("Hello" + s + "!");}}); } The observable pattern with subscriber 02. OTHER LANGUAGES

17 RxScala object Hello {def hello (names: String *) {Observable.from (names) subscribe {n => println (s "hello $ n!")}}} The same in Scala. Many languages, one generic framework. 02. OTHER LANGUAGES

18 03 Go is different!

19 BRIAN KERNIGHAN Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

20 {A principle of Go Simplicity. 03. GO IS DIFFERENT Every part of the language should be easy to understand

21 The values ​​of Go Well thought out Simple E ffi cient Reliable Productive Friendly 03. GO IS DIFFERENT

22 DOES RxGo MATCH GO?

23 RxGo nexthandler: = func (item interface {}) interface {} {if num, ok: = item. (Int); ok {nums = append (nums, num)}} sub: = observable.subscribe (handlers.nextfunc (nexthandler)) The type safety of Go is discarded in order to apply a generic pattern 03. GO IS DIFFERENT

24 04 Basics

25 04 Go Basics

26 Go Basics Go is strictly typed! type User struct {Name string} You can initialize and declare in one step var i int i = 42 // or Go can infer types Functions are types too! 04. BASICS i: = 42

27 Go Basics Go functions look like this and can also have several return values ​​Errors are simply checked and handled Simple error handling 04. BASICS func Add (in int) (out int) {return in + in} func Do (in int) (out int , err error) {} result, err: = Do (42) if err! = nil {log.println (Oh no!)} ...

28 Concurrency is not parallelism ROB PIKE

29 Quite old-fashioned 04. BASICS

30 reactive! 04. BASICS

31 reactive! And in parallel! And scalable! 04. BASICS

32 Always more! 04. BASICS

33 04 goroutines

34 goroutines Instead of threads we use goroutines go dosomething () Go distributes goroutines to threads as required, even with anonymous functions go func () {// do stuff here ...} () goroutines are an abstraction of threads and save us coordination effort 04. BASICS

35 Goroutines go println (1) go println (2) go println (3) // Output could be: Goroutines run asynchronously from 04. BASICS

36 goroutines In goroutines we program imperatively in the normal way - that is, from top to bottom go func () {i: = 1 i = i * 2} () But how do we get results? func do (in string) (out string) {return output: + in} go do (Hello) Within a goroutine we program imperatively 04. BASICS // How do we get the output?

37 04 channels

38 Channels Channels have a type Unbuffered or buffered channels are normal values ​​and can be used as parameters Or as return values ​​mychannel: = make (chan string, 0) mybufferedchannel: = make (chan string, 100) // Channel as a parameter func dosomething (mychannel chan string) // Channel as a result func dosomething () chan string Channels are thread-safe, ef fi cient queues and normal values ​​at the same time 04. BASICS

39 Channels You can read or write values ​​from the channels. // Read from channel myvalue: = <-mychannel // Write to channel mychannel <- myvalue Reading blocks until something is sent via the channel // Read from channel // Can take some time myvalue: = <-mychannel Channels are thread-safe , ef fi cient queues and normal values ​​at the same time 04. BASICS

40 channels Writing blocked without buffer mychannel: = make (chan string, 0) ... until someone starts to read // Write to channel blocks mychannel <- myvalue With buffer there is no blocking until the buffer is full // With buffer of size 1 mychannel: = make (chan string, 1) mychannel <- myvalue // Does NOT block mychannel <- myvalue // DOES block channels are thread-safe, ef fi cient queues and normal values ​​at the same time 04. BASICS

41 04 Goroutines & Channels

42 Channels & Goroutines Channels can be used by several Goroutines mychannel: = make (chan string, 0) go func () {mychannel <- Hello} () go func () {mychannel <- World} () to exchange values! go func () {for {print (<- mychannel)}} () // Output: Hello World We use channels to communicate between goroutines. Each value is only distributed once. 04. BASICS

43 channels & goroutines for all types! type User struct {Name string Age int} mychannel: = make (chan User, 0) to organize complex tasks e ffi ciently go func () {for {newuser: = <-mychannel saveuserindb (newuser)}} () We communicate with channels between goroutines 04. BASICS

44 04 workers

45 workers Workers return an input and output channel. func StartWorker () (chan input, chan output) {// do stuff} You are already listening to the input! Documentation through strict type security! Errors are normal and part of the type Input struct {type Result struct {Name string Data string} Error error} return. Types document input and output, but cost a few lines of Code 04. BASICS

46 Chaining connection of channels creates a reactive chain output: = <-outputchannel newdata: = output +! otherinputchannel <- otherinput {content: newdata} Trivial error handling. output: = <-outputchannel if output.error! = nil {fmt.println (output.error.error ()) break} Orchestration in one place - this is where the threads come together 04. BASICS

47 Advanced - Easily expandable type signalbroadcaster struct {lock sync.rwmutex sigchans [] chan os.signal} func (s * signalbroadcaster) Broadcast (sig os.signal) {s.lock.rlock () for i: = range s.sigchans {s.sigchans [i] <- sig} s.lock.runlock ()} func (s * signalbroadcaster) Add (sigChan chan os.signal) {s.lock.lock () s.sigchans = append (s.sigchans , sigchan) s.lock.unlock ()} If we want we can easily create complex stream operations 04. BASICS

48 05 Live coding

49 06 Conclusion

50 01 Documentation including 01. REACTIVE?

51 02 A lot of security during compile and development time 01. REACTIVE?

52 02 Easy debugging 01. REACTIVE?

53 01 But: More trivial code! 01. REACTIVE?

54 END More information

55 More info + Concurrency is not parallelism + ReactiveX + The code on Github END