YJS란

참고 자료

https://www.tag1consulting.com/blog/deep-dive-real-time-collaborative-editing-solutions-tagteamtalk-001-0

YJS의 목적

• 실시간 협업 솔루션에 대한 필요성.
• 인트라넷, 이미 존재하는 서비스 등에 실시간 협업 기능을 쉽게 추가할 수 있는 방법이 있으면 했다고 함.

동시 편집, CRDT의 핵심

• CRDT의 기본은 position-based가 아니라 모든 캐릭터에 대해 identifier를 두는 것.

  <aside>

  “this is some text"와 같은 텍스트가 있다고 하자. A, B가 이를 동시에 편집 중이다.

  A의 커서는 맨 앞에, position 0에 있다.

  B의 커서는 “some” 뒤, position 12에 있다.

  이 때, A는 “hello”를, B는 “nice”를 추가하고 싶다. 결국 동시 편집 상 원하는 결과는 “hello this is some nice text”이다.

  이 때, 각자의 position을 기준으로 동시편집이 이루어지면 A의 “hello”에 의해 기존 텍스트가 밀려나면서 “hello this is nice some text”와 같이 원하는 것과 다른 결과가 나올 수 있다.

  이를 해결하기 위해 마치 사람이 이 문제를 해결하듯이, B의 “nice”를 position 12가 아닌, “some” 뒤에 추가하는 것이 CRDT의 기본적인 해결 방법이다.

  </aside>

Decentralized Approach

• Operational Transformation을 사용하는 기존의 솔루션들은 서버에서 동시성을 해결해주는 중앙화된 방식으로 동작한다. 단점은 제한된 동시성이다. 서버와 클라이언트 사이에서만 동시성이 존재하기 때문에. 또 이 서버가 single point of failure가 되기도 한다.
• YJS, 혹은 CRDT는 이와 달리 좀 더 분산화된 방식을 채택하고 있다. CRDT는 변화가 어떤 순서로 들어오든지 같은 결과를 갖게 되기 때문에 중앙된 서버에 의존하지 않아도 된다. 이에 대한 장점은 중앙에 모이지 않으니 scalable하다는 것도 있고, 서버 연결이 되지 않는 비행기와 같은 공간에서도 한 팀이 같이 작업할 수 있다는 점도 있다.

Edit History와 Undo/Redo

• Operational Transformation에서는 해당 문서의 history가 존재하기 때문에. Undo/Redo가 어렵지 않다.
• 반면 CRDT에서는 그런 linear한 history가 없다. 트리 구조(정확히는 DAG인듯)를 띄기 때문에 Undo/Redo 시에는 이에 대한 경로와 state를 통해 해결하는데, 결론적으로는 잘 해결되어 있는 문제인 것 같다. 이를 위해 Undo Manager가 구현되어 있는데 문서의 scope와 권한의 scope를 지정해줄 수 있다.
• 결국 고려할 사항은 유저가 Undo/Redo를 했을 때, 어떤 어떤 문서까지 수정할 것인지(현재 편집 중인 문서, 존재하는 모든 문서), 다른 유저가 수정한 것을 Undo/Redo할 것인지가 된다.

YJS와 Shared Types