Younho9 NotesRxJS 퀵스타트
RxJS를 시작하기 전에
RxJS가 어떤 기술적 고민을 토대로 탄생했는지, RxJS가 무엇인지 간략하게 살펴보도록 하자.
- 웹 환경의 변화 - Ajax의 도입으로 새로운 페이지 요청 없이 데이터를 가져올 수 있게 되었다. - Web Storage, Web Wor템 ker 등 애플리케이션 구성에 필요한 기술들을 브라우저에서 지원할 수 있게 되었다.
- 웹 개발 복잡도 증가 - 웹 환경의 변화로 인해 웹 서비스 개발은 더욱 더 복잡해졌다.
- 웹 애플리케이션은 상태 머신이다.
- 웹 애플리케이션 오류가 발생하는 경우 1. 입력 오류 2. 상태 오류 3. 로직 오류
RxJS는 입력 오류, 상태 오류, 로직 오류로 인해 발생하는 문제를 효과적으로 처리하기 위한 고민의 산출물이다. 궁극적으로 RxJS는 오류가 발생하지 않는 애플리케이션을 만들기 위해 일관된 방식으로 안전하게 데이터 흐름을 처리하도록 도와주는 라이브러리이다.
RxJS가 해결하려고 했던 문제 1 - 입력 데이터의 오류
RxJS가 해결하려고했던 문제1 - 입력 데이터의 오류 | 아내와 아들 그리고 딸밖에 모르는 남편 (sculove.github.io)
첫 번째로 RxJS가 입력 오류 중 어떤 부분을 개선하고자 했고, 어떻게 개선하려고 했는지 살펴보자.
동기 vs 비동기
동기
- 호출하는 함수가 호출되는 함수의 작업 완료를 기다린 후 그 다음을 진행한다.
- 처리하는 작업이 많을 경우에 전체 작업 속도가 느려진다.
비동기
- 호출하는 함수가 호출되는 함수의 작업 완료를 기다리지 않고 그 다음을 진행한다.
- 처리 시간이 오래 걸리더라도 다른 작업을 진행할 수 있다.
- 호출 순서를 보장하기 어렵기 때문에 더욱 복잡해지고 오류 확률이 높아진다.
RxJS는 어떻게 개선하였나?
RxJS는 동기와 비동기의 차이점을 시간이라는 개념을 도입함으로써 해결하려고 했다.
- 동기와 비동기는 시간의 축으로 봤을 때는 같은 형태이다.
- 시간을 인덱스로 둔 컬렉션으로 생각할 수도 있다.
- 이를 스트림(stream)이라 표현한다.
- RxJS는 스트림을 표현하는 Observable 클래스를 제공한다.
Observable
- 시간을 인덱스로 둔 컬렉션을 추상화한 클래스이다.
- 동기나 비동기로 전달된 데이터를 하나의 컬렉션으로 바라볼 수 있게 해준다.
- 모든 데이터는 Observable 인스턴스로 만들 수 있다.
- 이렇게 함으로 모든 데이터 타입을 동일한 형태로 사용할 수 있다.
정리
- RxJS는 입력 데이터 전달 방식의 구조적 문제를 시간을 인덱스로 둔 컬렉션으로 추상화시킴으로써 동기와 비동기 입력 데이터를 하나의 컬렉션으로 생각할 수 있게 하였다.
- 이를 스트림(Stream)이라 부르며 그 구현체가 Observable 클래스이다.
- Observable은 모든 데이터를 표현할 수 있는 일원화된 데이터 구조이다.
RxJS가 해결하려고 했던 문제 2 - 상태 전파 문제
RxJS가 해결하려고했던 문제2 - 상태 전파 문제 | 아내와 아들 그리고 딸밖에 모르는 남편 (sculove.github.io)
상태 머신에서 가장 흔하게 발생하는 상태 전파(state propagation)에 대한 이야기이다. RxJS가 상태 전파에 대한 문제를 어떻게 접근했고, 이를 어떻게 해결하려고 했는지 이 장을 통해 살펴보자.
웹 애플리케이션의 상태
RxJS Quick Start - Chapter 2. 웹 애플리케이션의 상태 - StackBlitz
위의 예제의 문제점
- User의 인터페이스가 변경되면 System도 함께 변경해야 한다.
- User 상태를 확인하기 위한 인터페이스에 대한 의사소통 비용이 발생한다.
- 다수의 클래스가 User에 의존 관계가 있는 경우라면 User의 변경 여부를 반영하기 위해 다수의 클래스들이 직접 User의 상태를 모두 반영해야 한다.
옵저버 패턴으로 느슨하게 연결함으로 대부분 해결할 수 있다.
"느슨하게 연결되었다(Loosely Coupling)"의 의미는 서로 상호작용을 하지만 서로 잘 모른다는 뜻이다.
옵저버 패턴은 의존 관계의 대상(Subject)로 부터 데이터를 제공받는 Push 방식이다. Push 방식은 Pull 방식에 비해 상태 전파 문제를 효과적으로 처리할 수 있다. 특히 1:N의 상황에서는 더욱 효과적이다. 데이터 변경 시점을 매번 확인할 필요도 없고 신경 쓸 필요도 없다.
RxJS Quick Start - Chapter 2. observer pattern (stackblitz.com)
RxJS는 무엇을 해결하고자 했는가?
옵저버 패턴에서 아쉬웠던 몇 가지를 개선했다. 앞선 예에서 뉴스 서비스 종료로 뉴스를 전달하지 않게 되었다면, 어떻게 구독자들에게 이를 전달할 수 있는가? 서비스 종료라는 특정 문자를 각 구독자에게 보내야 한다. 이는 언제 종료되는지에 대해 별도의 의사소통 규칙을 정해야 하는 것이다. -> 코드로 이어진다.
상태 변화에서 에러가 발생하면? 에러가 발생하는 것을 Subject에서 자체적으로 처리할 수 있다. 하지만 어느 경우에는 옵저버 쪽에서 에러 발생 여부를 인지하고, 이에 대해 별도의 처리를 해야 하는 경우가 필요하다. 옵저버 패턴에서는 update 인터페이스 만을 통해서 전달하기 때문에 처리하기 어렵다.
옵저버에 의해 Subject의 상태가 변경되는 경우는? 신문사 기자이면서 동시에 구독자인 사람의 경우라면, Subject를 관찰하는 Observer가 Subject의 상태를 변경하는 경우에는 우리가 예상하지 못하는 복잡한 상황에 직면하게 될 수 있다.
RxJS는 어떻게 개선하였나?
Observable은 구독 과정 후부터 데이터를 전달받기 시작한다. 옵저버 패턴에서는 Subject와 Observer가 add 과정 후부터 데이터를 전달받기 시작한다.
HTTP 완벽 가이드 스터디
- 스터디 방식
- 요약 보다 질문할 거를 모아놓자
- 문서 기반의 정리를 지양하자
1장에 20p ~ 30p
21장
1주 -> 2장 => 10주 => 2달 ~
2장
1회차 연호 / 응재 1, 2 2회차 영수 / 순현 3, 4 3회차 연호 / 응재 5, 6 ... ...
- 토론 방식의 스터디
- 각자 읽어오고, 중요하다고 생각한 점, 얘기해보고 싶은 점, 새롭게 알게된점 .. 등등 그냥 생각해오고 토론 하기
차차주까지 5월 2일 주까지 1, 2장 읽어오기