optimistic update에 대해 찾아 보게 된 것은 현재 진행하고 있는 토이 프로젝트 때문이었다. 토이프로젝트에서 우선 server랑 db없이 state management만으로 CRUD 기능을 만들어보았다. 그 후 server db에 저장할 필요성이 있었기 때문에 state 상태와 server db의 상태를 sync 맞추기 위해 구글링 하던 중, 크게 두가지 방향이 있다는 것을 알아냈다.
- db를 먼저 바꾸고, 그 후 state를 바꾸는 방법
- state를 먼저 바꾸고, 그 후 db를 바꾸는 방법
2번째 방법을 optimistic update라고 한다. optimistic이 붙은 이유는 state를 다루는 client가 db변경에 대해 에러가 없을 것이라고 긍정적인 전제를 깔고 행하기 때문이다.
state를 먼저 바꾸는 optimistic update의 장점은 user 친화적이라는 것이다. 금방 금방 자신의 input이 반영되기 원하는 user들에게 optimistic update는 빠른 변경을 경험하게 해준다.
반면 단점으로는 에러 처리가 까다롭다는 점이 있다. db에서 처리되지 못하고 에러를 던져줄 경우, 이미 state는 변경된 상태이다. 이 때는 에러가 있었다는 것을 알리고 state를 이전으로 되돌려야 한다. db를 먼저 바꾸는 1번 방법에 비해 에러 처리 과정이 좀 더 번거로운 셈이다.
사람에 따라서 optimistic update의 찬성과 반대가 있었다. user experience를 중요하게 여기는 사람들은 optimistic update에 긍정적인 편이었고, 그보다 확실성을 중요시 여기는 사람들은 1번 방법을 더 선호하였다.
결국 정답은 없고, 장단점을 파악하고 난 후 결정의 몫은 나의 것이다. 나의 현재 토이 프로젝트의 경우 이미 state단에서 CRUD 기능이 구현되어있었다. 그리고 개인적으로 요즘 시대에는 user experience가 더 중요시 된다고 생각한다. 그래서 optimistic update를 적용하여 state의 결과를 db에 반영하는 식으로 만들어 보기로 했다.
참고자료
- reddit discussion about optimistic update
- what method to sync UI state and server db
- optimistic and pessimistic UI rendering approaches
0 comments:
댓글 쓰기