Facebook: MVC Does Not Scale, Use Flux Instead

  • Facebook은 “MVC는 스케일하지 않다” 라고 결론을 내렸다.
    • MVC는 확장에 어울리지 않는다.
    • MVC는 거대한 시스템에 어울리지 않는다.
  • 이유
    • 새로운 기능을 추가할때 마다 시스템의 복잡도는 기하급수적으로 증가.
    • 그래서 프로그래머가 “기존의 기능에 영향을 주지 않을까?” 라는 생각을 하게 만들고.
    • 기능 추가에 두려움을 주게 된다.
    • MVC는 작은 앱에 어울린다. 하지만 모델, 뷰의 수가 커지면.
      • 모델 과 뷰 사이의 데이터 흐름이 양방향으로 이루어질 수 있어서,
      • 복잡도가 폭발적으로 증가하고.
      • 이해하기도 힘들고 디버깅도 어려워진다.
  • 그래서 우리는 MVC 와 결별했다.
  • 대안의 목적은 “좀더 예측가능하도록 코드를 구조화하는 것”
  • Flux 와 React 로 이 목적을 달성했다.
    • Flux: 데이터 흐름이 단 방향인 시스템 아키텍처.
    • React: “predictable” 하고 “declarative” 한 웹 유저 인터페이스를 빠르게 만들기 위한 JavaScript framework
    • Store: App의 모든 데이터 저장
      • MVC의 Model과 다른 점은 1개의 객체 인스턴스가 아니라, 여러 객체의 상태를 관리한다는 점.
    • Dispatcher: Controller 역할. Action 이 시작될때 어떻게 Store가 업데이트 되어야 하는지 결정.
      • 모든 데이터를 관리하는 중앙 허브.
      • Store의 콜백이 등록된 장소라고 이해하면 됨.
    • Store 가 변경된 경우 View 도 변경됨.
    • 데이터는 단방향으로만 흐르고, Store와 View는 서로 직접적으로 영향을 줄 수 없다.
    • 중요한점은 데이터 계층이 자기가 영향을 미치는 view 를 업데이트 완료하고 난 이후, 다른 작업을 진행한다는 점.
  • 샘플로 Flux TodoMVC Tutorial 를 보면 과정을 좀 더 자세히 알 수 있다.

논란

위의 글이 올라간 이후로. Reddit에는 수많은 논쟁 이 있었다. 재밌는 코멘트:

  • Facebook 이 MVC를 잘못 이해하고 있다. 정통 MVC는 이런 모양이다.
    • Facebook 은 아마도 여러 모델을 컨트롤하는데 1개의 컨트롤러를 쓰려고 노력했을 것이다.
  • 이것은 Facebook이 MVC에 새로운 이름을 붙인 것이다.
  • 이 아키텍처는 MVC를 조금만 변형하여 이벤트기반 형태로 만든 것이다.
    • Store는 자신과 호출순서의 의존성을 콜백 형태로 Dispatcher에 등록하고.
    • Dispatcher는 호출순서를 보장하면서 작업을 처리하는 역할인듯 하다.
    • 이것은 Controller의 역할을 Dispatcher와 Store가 하게되는 형태이다.