[Reactive-X, WebFlux] 간단 정리

내가 처음 리액티브를 많이 듣게 된 건 토비의 봄이었다

토비님도 이 Rx를 공부하는 데 많은 어려움이 있었고 몇 개월이 지나서야 감을 찾기 시작했다고 한다

 

Rx (Reactive Extensions)를 만든 MicroSoft 엔지니어들은 기존의 옵저버 패턴의 한계를 크게 2가지 지목했다고 한다

 

1. 도대체 이벤트는 언제 완료 되는가?

2. Error 핸들링을 어떻게 하는가?

 

옵저버 패턴에는 위 2개에 대한 기본 골조(아이디어)가 없다고 한다

이 2가지가 추가된 확장된 옵저버 패턴인 Observable이 Rx의 세 가지 축 중 하나의 축이 된다 

(세 가지 축은 Observable, Scheduler, Observer를 말하는 것 같다)

 

 

Reactive System

클라이언트와 맞장구를 잘 쳐주는 시스템

클라이언트가 바쁘면 천천히 얘기를 하고, 한가하면 많이 한다

 

메세지 기반으로 이루어졌고 이를 통해서 응답성을 일정하게 유지한다

 

선언형 프로그래밍 방식을 채택했다

 

 

구성 요소

- Publisher

- Subscriber

- Data Source

- Operator

 

발행자(Publisher)는 Data Source를 통해 구독자(Subscriber)에게 전달한다

전달하는 방식에 Operator를 사용한다 (변환 작업 등)

 

 

용어 정리

Signal

발행자와 구독자 사이의 신호 (상호작용)

예)

Publisher의 Signal

- onSubscribe, onNext, onError

 

Subscriber의 Signal

- request 

 

Demand

구독자가 발행자에게 요청하는 것 (request)

 

Emit

발행자가 구독자에게 데이터 전달하는 것

 

Upstream / DownStream

코드 상 Operator들에게 나타나는 상대 적인 개념이다

Flux.just(1, 2, 3)
	.map(n -> n*2)
	.subscribe { println(it) }

 

1번 라인은 2번 라인의 Upstream이다

2번 라인은 1번 라인의 Downstream이다

 

Sequance

Operator들로 구성된 데이터의 연속된 흐름

 

Operator

map, filter 등의 연산자

 

 

Cold Sequance, Hot Sequance

Cold  처음 부터 새로 시작

Hot 비교적 빨리 시작, 처음에 시작되는 같은 작업이 반복되지 않음

 

 

 

 

참고

토비의 봄리액티브 프로그래밍 서적