수면 위의 의문
얼마 전 토이 프로젝트로 투두리스트를 만들었다. context api + useReducer를 사용해 상태 관리를 해보기 위해서였다. 구현을 하다 보니 든 의문이 있었다. 서버에서 가져온 데이터를 클라이언트 쪽에서 저장하고 관리할 필요가 있나?였는데, 전부터 context api를 사용하며 이 의문을 가지고 있었다.
이번 투두리스트에서는 데이터를 주고받는 서버가 있었고 useReducer까지 사용해 데이터를 상태로 관리하다 보니 이게 필요한 일인가? 하는 생각이 더욱 크게 느껴졌다.
클라이언트에서 관리할 필요가 있나?라는 의문을 좀 더 풀어보면,
- 서버에서 받은 데이터를 바로 렌더링 하면 그게 제일 최신 데이터인데 굳이?
- 클라이언트에서 관리하다 보면 서버와 클라이언트 데이터 사이에 차이점이 생기는 문제가 발생할 수 있을 듯?
- context api는 전역 상태를 관리하기 위한 도구인데 서버에서 받아온 데이터가 전역 상태인가? (전역 상태이기 전에 상태인가? 가 먼저...)
고민의 답
이번에 넘블 프로젝트에 참여하며 사용할 기술 스택을 고르며 전역 상태 관리 도구를 선택해야 했다. redux, recoil, react-query를 찾아봤다. 그러면서 위 의문의 답도 찾을 수 있었다.
1번 - 서버에서 받은 데이터를 바로 렌더링 하면 그게 제일 최신 데이터인데 굳이?
서버에서 받아온 데이터를 클라이언트 쪽에 저장해두는 것을 캐싱이라고 한다. (캐싱에 대해서 막연하게는 알고 있었는데 왜 이게 캐싱이라고 연관을 못 지었을까...)
캐싱을 해두면 api 콜을 줄일 수 있어 서버에 대한 부담을 줄일 수 있다.
2번 - 클라이언트에서 관리하다 보면 서버와 클라이언트 데이터 사이에 차이점이 생기는 문제가 발생할 수 있을 듯?
맞다. 이런 문제가 발생할 수 있어서 잘 관리해야 한다. react-query에서는 기본적으로 데이터를 fetching 해온 후 데이터를 캐싱하고, 해당 데이터가 최신 데이터가 아니라고 판단되면 refetching 한다고 한다.
3번 - context api는 전역 상태를 관리하기 위한 도구인데 서버에서 받아온 데이터가 전역 상태인가? (전역 상태이기 전에 상태인가? 가 먼저...)
그래서 react-query를 사용하면 서버 데이터를 관리하게 되고, context api, redux, recoil같은 라이브러리들을 온전히 클라이언트 영역의 전역 상태 관리 도구로 사용할 수 있게 되는 장점이 있다고 한다.
모두의 고민
찾아보며 나만 고민한 게 아니구나, 고민이 옳은 방향이었구나를 느껴서 뿌듯뿌듯
