RIBs (미완성)

RIBs

https://github.com/uber/RIBs

GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.

 

Modern RIBs (RxSwift를 걷어내고 Combine을 사용한 RIBs)

https://github.com/DevYeom/ModernRIBs

GitHub - DevYeom/ModernRIBs: Uber's RIBs with Combine.

 

RIBs ?

핵심 요소( 기능 단위이며 한 묶음을 Riblet이라고 부름 )

 

Router ( Helper For Routing Between RIBs )

• RIB 상에서 Interactor의 business logic에서 일어나는 routing들을 좀 도와주는 Helper

Interactor ( Business logic( a.k.a Brain Of the App ) )

• RIB의 비즈니스 로직을 담당하는 가장 중요한 컴포넌트이다.
• API가 어떻게 호출되는지 
• 데이터를 어떻게 적는지
• State들을 어떻게 관리하는지 
• 앞으로 어떤 State로 갈지 판단

Builder ( Build RIB units )

• Factory 패턴으로 RIB 컴포넌트들을 생성해주는 역할을 한다.
• 각 클래스 생성 로직들이 Builder로 들어가게 돼서 컴포넌트들의 mockability 향상시켜주는 역할
• Builder는 RIB 컴포넌트들을 만들어주기 때문에 A라는 RIB의 Interactor와 B라는 RIB의 Router를 꺼내서 새로운 C라는 RIB을 만들 수 있어 재사용성이 좋은 툴이다.

 

+

 

추가 요소 

Presenter ( Translation logic )

• View Logic이 필요할 때만 추가되는 Component
• Interactor에서 나오는 정보들이 너무 부족하거나 많아 이걸 직접 View에서 사용하기에 적합하지 않을 때가 있다. 따라서 이 데이터 모델들을 뷰가 해석할 수 있는 형태로 변형해주고 반대로 뷰에서 일어나는 각종 Action들을 Interactor가 해석할 수 있는 형태로 변형해주는 translation logic을 담당하는 역할

 

View ( Layout & Animation )

• 현재 상태를 화면에 보여주고 User Interaction을 받고 Animation을 처리해주는 요소들이 들어간다.  

 

 

 

 

다양한 아키텍처 패턴이 있지만
왜?
RIBs를 사용했을까?

 

 

 

타다의 사례

타다는 오토 서비스이기 때문에 타다 Driver App과 타다 Rider App을 동시에 만들어서 출시를 했어야 했어야 했고, 이 과정에서 타다가 느낀 비효율성들이 있었다. 

 

1. 각 피처를 구현해야할 때 각 os 팀에서 똑같은 고민을 한다.

2. 똑같은 로직을 구현하는데 iOS, AOS 팀들 각자 시간이 소요된다.

3. 또 로직이 구현이 살짝 달라지기 때문에 디버깅하는데 각자의 시간이 또 든다.

 

이런 비효율들을 가능한 없애자는 생각에서 시작하게 되었다.

 

"os에 상관없이 아키텍처 패턴을 통일시켜 놔서 정해진 패턴대로 개발을 하면 우리가 좀 더 로직에 집중할 수 있지 않을까?"

 

그러기 위해서는 새로운 아키텍처 패턴을 정의해서 사용해보자!

 

새로운 아키텍처 패턴을 고려했을 때 고민했던 3가지

• No MVC, MVVM, MVP ( Massive series )
• Map-base application ( 많은 화면들이 Map을 기반으로 움직이기 때문에 Overhead가 자주 발생할 수 있다. )
• No time to create a framework from scratch ( AOS : Conductor, Scoop 등 iOS : Redux, ReactorKit, Reflex, VIPER 등  )

 

이 모든 것을 고려해서 선택한 것이 RIBs 이다.

 

 

 

RIBs의 진짜 이점 

RIBs는 컴포넌트들의 밸런스를 맞추는 것 보다 실질적으로 RIBs를 사용하면서 얻는 이점은 State 관리에 있다.

 

 

Uber에서 보인 State Machine 이미지

 

모바일에서는 전체 App에서 다뤄야하는 State들이 굉장히 많아진다. 화면이 작고, 화면 마다 제공하는 기능이 엮여있기도 하고, 분리되어 있기도 하다. 그래서 그림으로 표현하게 되면 이렇게 간선들이 복잡하고, 많아질 수 밖에 없게 된다. 

 

State들이 많지만 비슷한 역할을 하는 로직이 붙어있는 경우도 있고, 또 어떤 스코프 안에서 동작하는 화면일 수도 있다. 

따라서 Uber는 이런 점들을 고려해서 모든 State들을 tree형태로 만들 수 있지 않을까 라는 생각을 시작으로 RIBs를 시작하게 되었다.

 

참고

https://youtu.be/FmnshYCDeW8

https://blog-tech.tadatada.com/2019-05-08-tada-client-development