Review Uber/RIBs (a mobile app architecture) after 2 weeks of use.

Uber has opened source their mobile architecure RIBs (https://github.com/uber/RIBs) since 2017. But I just had the opportunity to know about it 2 weeks ago. I appreciate technology companies sharing how they build applications that change the world.

As they said RIBs was born to resolve many problems which previous architecture they used (MVC) could not.

• Business logic tied to UI.
• Massive View Controller.

(see more: https://eng.uber.com/rewrite-uber-carbon-app)

I’m quite impressed with this architecture and think that I should share with everyone about its strength and limitations. Of course on my point of view and welcome anyone’s opinion.

Alright, beginning with GOOD points:

• Open source: An important thing RIBs is an open source project. So no limit You have the right to change everything which suitable with your app.
• Tooling: Uber engineers added a codegen extensions which enables to create a RIBs quickly with a lot of configs between components.
• Isolation: RIBs uses protocols/interfaces for dependencies. So a RIBs will completely independent with others. Each of components just depends on abstract layer and they are composed together by builder only. This is important if you want to develop many features simultaneously and not be blocked by other things.

• Testable ability: As previous point, RIBs uses protocols for every dependencies so it is absolute for testing, especially mocking objects. Another characteristic is a RIBs may has no views, but it has its own life cycle. This allows you to test many complex logic while not having a view controller for navigating.

Powerful but also has downsides:

• Application state makes decision business structure & logic: RIBs manages application state as a tree of states. Each of node corresponds a RIB. When a state changes might affect to business logic in RIB. This seems like an anti-pattern when changes at high level leads to changes at lower level.
  Eg: A -> B -> C (interactor of B has logic to detach C)
  => A -> C -> B (logic to detach C move to interactor of A). Here when application state layer changes, I don’t expect to change business logic layer (interactor).

• Parent-children of business (RIB) makes leaks of control flow: interactor’s listener keeps routing role, also it enables to communicate between 2 interactors in 2 RIBs while this role should belong to router only. So an interactor has 2 reasons to change for a single business logic. Routers & listeners broke unified logic flow. I think it soft violated SRP.
• Deep state hierarchies / Nested application state might causes of logic complexity: Although there are some benefits when developing (see more: https://eng.uber.com/deep-scope-hierarchies) but a nested state is not recommended. When state of higher RIB passed through states tree to a leaf RIB, this RIB listen changes of that state, when something went wrong we will need a smart business man to find where is the souce of changes. So a flat application state for each module is better than a so deep one in this concern.
• Fastened with Functional Reactive Programing (FRP): you can implement RIBs with a non-FRP diagram. But core of architecture depends on FRP. And to take advantages of the deep state hierarchy you are recommended to use it.

Conclusion

Any architectures has good points and bad points. The analysis helps promote advantages and prevent disadvantages. If you have a huge team, you focus on isolation and testable ability and familiar with FRP. This is a choice to consider.

Thank you for reading!