소켓으로 인한 상태관리의 복잡성과 데이터 흐름 변경
주차별로 기능을 하나씩 추가하다보니, 실시간 협업 기능이 추가되면서 기존 REST 구조에 소켓 통신을 더하게 되었다. 이미 구현된 API들을 활용하다보니 일부는 YDoc(YJS.Doc)의 상태를 사용하면서도 일부는 서버 상태로 남게 되었다.
노트 목록의 초기값도 서버로부터 클라이언트가 받아와서 이를 YJS에 넣는 방식이었고, 유저 액션에 따라 노트 목록에 변경이 생겨도 이를 서버에 보낸 후, query를 invalidate해서 서버 상태로부터 YDoc에 변경된 값을 넣어줬다. 그리고 YDoc의 변경을 감지해서 다시 이를 리액트 클라이언트 상태에 넣어주는 다소 복잡한 방식이었다.
그러다보니 상태 관리의 복잡도 또한 증가했고 race condition을 예측하기도 어려워졌다. 또 일관되지 못한 데이터 흐름으로 인해 에러 처리 난이도가 증가했고 그 결과 5주차 데모 중, 미리 처리하지 못한 에러에 의해 서버가 다운되는 상황 또한 발생했다.
복잡도를 낮추고 에러 처리를 제대로 하기 위해서, 우선 전체적인 데이터 흐름에 대해 다시 생각해보게 되었다. 수정을 가하기 전에 변경하기 쉬운 구조로 바꾸는게 우선이라는 판단이었다.
협업 중, Y.Doc을 Single Source of Truth으로 사용하게 변경했다. 첫 로딩 시, 비어 있는 Y.Doc에 DB로부터 데이터를 로드했고, 도큐먼트에 변경이 생기면 이를 DB에 저장하는 일관된 방식으로 수정했다.
그러고 나니 서버 상태와 Y.Doc의 상태를 둘다 관리하던 방식에서 Y.Doc만을 사용하는 방식으로 변경이 가능했고, 이Y.Doc은 전역 스토어에 등록해서 다른 컴포넌트에서도 그 변화를 감지해서 다시 렌더링이 일어나게 하거나, 그 값을 바꿔줄 수 있게 만들었다. 이렇게 데이터 흐름과 상태를 일관되게 정리하고 나니, 기존에 두 가지 상태 사이의 race condition 문제도 자연스럽게 사라지고 예상하지 못한 edge case들도 줄어들어 안정적인 로직을 구성할 수 있었다.