[iOS] RIBs?

RIBs

오늘은 RIBs에 대하여 공부를 해보려고 합니다.

 

그동안 Swift 관련 커뮤니티 등에서 익히 들었는데 공부는 처음 하게 되었습니다.

 

RIBs 란 무엇인지 간단히 알아보고 RIBs framework를 만든 Uber에서 제공하는 Tutorial을 진행해보며 감을 익혀보려고 합니다.

 

그러면 본격적으로 RIBs 가 무엇인지 알아보도록 하죠!

 

 

RIBs는 Cross-Platform Mobile Architecture framework라고 합니다. (공식 레포지토리를 살펴보면 android와 iOS 디렉토리가 별개로 제공되고 있습니다.)

 

RIBs는 RIB이란 단위의 복수형을 의미하며 RIB은 Router, Interactor, Builder의 약자라고 하며 이 세 가지 컴포넌트가 해당 Architecture의 핵심입니다.

 

RIBs Architecture는 중첩된 상태 & 수많은 엔지니어들의 협업에 능하도록 고안되었습니다.

 

RIBs Architecture를 이용하면 아래와 같은 이점을 얻을 수 있다고 합니다.

 

• Shared architecture across iOS and Android.
  • iOS와 Android의 모바일 앱 구조를 공유할 수 있다고 합니다, Croos-Platform을 제공하기에 각각의 팀의 비즈니스 로직에 대한 교차 검토가 가능해집니다.
• Testability and Isolation.
  • Class는 단위 테스트가 용이하도록 설계되어야 합니다. RIBs에서 개별 RIB 클래스들에게는 각각의 "책임"이 존재하게 되는데 책임 내부에는 Routing, Business Logic, View Logic, Creation 등이 포함되며 parent RIB과 child RIB 간의 분리를 통해 RIB 클래스를 보다 쉽게 테스트할 수 있도록 해줍니다.
• Tooling for developer productivity.
  • RIBs는 IDE tooling을 제공하여 bolierplate code 생성 기능을 제공하는 등 다양한 IDE tooling 제공을 통해 개발팀 생산성을 향상시킵니다.
• An Architecture that scales.
  • RIBs Architectures는 수많은 RIBs로 구성된 동일한 code-base 어플리케이션 소스코드를 수백 명의 엔지니어들이 함께 작업하기에 용이합니다.

음.. 네 RIBs를 이용하면 위와 같이 다양한 이점을 얻을 수 있다고 하는데요 (사실 잘 와닿지는 않습니다ㅎ)

 

그렇다면 MV*/VIPER Architecture 패턴들과는 어떤 차이점이 있는지 살펴보겠습니다.

 

MVC, MVP, MVI, MVVM 그리고 VIPER는 Architecture 패턴을 의미하지만 RIBs는 프레임워크입니다.

 

Architecture 패턴과 프레임워크의 차이점에 대해 살펴보도록 할게요.

 

• Business logic drives the app, not the view tree.
  • MV*/VIPER 패턴과는 달리 RIB은 view를 가지지 않을 수도 있습니다. 이는 앱의 구조가 View-driven 이 아닌 Business Logic-driven으로 구성된다는 의미입니다.
• Independent business logic and view trees.
  • RIB의 비즈니스 로직 구조는 UI 구조를 엄격히 반영할 필요가 없습니다. (비즈니스 로직 기반으로 앱의 구조가 결정된다는 의미인 것 같습니다..?)

흠.. 정리해보면 RIBs는 RIB이라는 단위를 기반으로 앱의 구조를 설계하는데 해당 RIB은 앱의 Business-Logic에 의해 상태가 결정된다는 것 같아요.

 

그럼 RIB이라는 단위를 구성하는 컴포넌트들과 각각의 컴포넌트가 갖는 역할 및 책임에 대하여 알아보도록 할게요.

Interactor

---

Interactor는 비즈니스 로직을 포함하며 아래와 같은 작업들을 진행합니다.

• Rx Sequence에 대한 Subscription 수행.
• child RIB을 붙일지 말지 결정.
• RIB의 state 변경에 대한 결정권을 가짐.
• 부모 자식 RIB 간의 통신.

MVVM에서 ViewModel의 역할과 어느 정도는 유사한 것 같아요.

 

Router

---

Router는 이름만 봐도 어느 정도 느낌이 옵니다.

 

앞서 Interactor 가 RIB의 state 변경에 대한 결정권을 가지며 다른 RIB을 붙일지 말지에 대한 결정권을 갖는다고 했잖아요?

 

Router는 이러한 Interactor를 바라보고 있다가(원문에서는 listening 한다고 표현) RIBs를 붙이거나 떼버리거나 합니다.

 

즉 Interactor의 결정이 내려오면 RIB 노드를 attach 하거나 detach 하는 작업을 진행하여 논리적인 트리 구조를 형성합니다.

 

Builder

---

Builder는 RIB의 모든 컴포넌트를 생성하고 DI를 정의합니다. 즉 Router, Interactor, View, Component를 생성합니다.

 

각 컴포넌트 클래스들을 생성하고 자식 Interactor와 부모 Interactor의 Listenr 인터페이스 연결을 구성하고 Router를 Output으로 반환하게 됩니다.

 

Builder는 본인의 역할을 위해서 프로토콜 Buildable 과 클래스 Builder가 존재합니다.

 

View

---

View는 UI 화면을 구성하고 생성하며, 사용자로 부터 들어온 UI Event를 Presenter에게 전달하거나 UI를 업데이트하는 역할을 합니다.

 

Presenter

---

Presenter는 비즈니스 로직을 수행하는 Interactor와 UI를 구성하는 View 사이에서 통신을 담당합니다.

 

Router, Interactor, Builder 이 세 가지 컴포넌트가 RIB의 필수 구성 요소이며 그 외 Optional로 View와 Presenter라는 컴포넌트가 존재합니다. 이 말은 즉 RIB 단위는 Business Logic만 갖는 View-less 한 형태의 RIB 생성이 가능하다는 의미입니다.

 

RIBs Tree

RIBs 비즈니스 로직에 의해 결정된 App의 State에 따라 논리적 트리 구조를 형성하며, 부모 RIB과 자식 RIB 간 통신을 진행합니다.

 

RIBs 간의 커뮤니케이션은 Interactor 가 담당하게 됩니다.

 

Interactor 가 비즈니스 로직에 대한 결정을 내릴 때, 다른 RIB에게 해당 결정 내용을 알리거나 데이터를 전달해야 하는 경우가 존재합니다.

 

• 상향 통신(child to parent): 자식 Interactor에서 부모 Interactor을 listener Interface를 통해 접근하여 통신.
• 하향 통신(parent to child): Observable Stream을 넘겨주어 통신.

 

이렇게 RIBs라는 Architecture Framework에 대하여 간단히 알아보았습니다.

 

RIBs에 대하여 본격적으로 공부하기에 앞서 간단히 살펴봤는데 사실 단순 문서만 봐서는 잘 이해가 되지는 않습니다.

 

이제 튜토리얼을 진행하며 RIBs에 대해 보다 자세히 살펴보도록 하겠습니다.

 

Reference

---

Uber - RIBs official repository