일찍이 별개의 그룹으로 분류했지만, 지금까지 설명한 내용으로 이터레이터와 Promise가 어떻게옵저버블로 래핑되는 잠재적 데이터 소스가 될 수 있는지를 알 수 있습니다. 교체하는 타입뿐만 아니라 다른 그룹의 타입을 조정하는 능력이 매우 좋아서 옵저버블이 동기와 비동기 경계에서도 잘 작동합니다. 이 덕분에 믿기 어려울 정도로 쉽게 레거시 코드와 인터페이싱하며, 생산자가 구현된 방식과 독립적으로 소비자 코드를 작성할 수 있습니다.
Warning
여기서 언급한 능력은 책임을 수반합니다. 생각한 것을 모두 Observable로 변경할 수 있지만, 그렇다고 필요하다는 뜻은 아닙니다. 특히, 엄격하게 동기화되고 반복적인 또는 단일 값만을 처리하는 절차를 멋져 보이려고 Rx화할 필요는 없습니다. Observable을 사용하는 데 드는 비용이 많지는 않지만, 데이터에 간단한 연산을 적용하는 데 따르는 약간의 오버헤드가 있습니다. 예를 들어 문자열을 소문자에서 대문자로 변환하는 경우에는 옵저버블로 래핑할 필요가 없으며 문자열 메서드를 직접 사용하면 됩니다. 할 수 있다고 모든 것을 꼭 사용할 필요는 없습니다.
RxJS에는 소스에서 해당 소비자로 데이터를 가져오는 파이프라인이 항상 있습니다. 데이터는 항상 데이터 소스에서 생성되거나 구체화됩니다. 다시 말해, 데이터 소스 타입은 추상화의 작업 방식과 관련이 없습니다. 데이터가 이동을 마치고 소비될 때 이 데이터가 어디에서 왔는지는 중요하지 않습니다. 다음 세 가지 이유로 데이터 생성과 데이터 소비라는 두 개념의 분리와 추상화가 중요하다는 점을 다시 강조합니다.
• 공통 인터페이스 뒤에 구현의 다른 점을 숨길 수 있으므로 작업의 비즈니스 로직에 좀 더 집중할 수 있습니다. 이 덕분에 개발 시간을 최적화하고 코드에서 추가 노이즈를 제거하여 코드의 복잡성을 줄일 수 있습니다.
• 생산과 소비를 분리하면 데이터 흐름의 방향이 분명해지고 염려되는 부분을 명확하게 분리할 수 있습니다.
• 생산자의 목(mock) 버전을 결합하고 옵저버가 기대하는 것과 상응하게 연결함으로써 스트림을 테스트할 수 있습니다.
스트림을 어떻게 구성하는지 살펴봤으니 이제 옵저버가 스트림을 소비하는 마지막 단계만 남았습니다.