React Query (stale-time, cache-time)

·2023년 6월 22일
0

개발 지식

목록 보기
93/96
post-thumbnail
post-custom-banner

Query의 상태

  1. fetching : 쿼리함수를 통해 서버에게 데이터를 요청하는 상태
  2. fresh : 서버에게 최신의 데이터를 받은 상태
  3. stale : 저장한 데이터가 더이상 최신이 아님을 뜻하는 상태
  4. inactive : 해당 데이터를 사용하는 모든 컴포넌트가 unmount 된 상태
  5. delete : 데이터가 캐시 저장소에서 완전히 사라진 상태

stale-time

Query 상태가 2 → 3 으로 변하는데 걸리는 시간을 의미한다.

즉, 데이터를 언제까지 fresh 상태로 둘 건지에 대한 범위를 설정하는 기능이다. 데이터가 fresh 상태인 경우, 쿼리 인스턴스가 새롭게 mount 되더라도 서버에 fetch 를 요청하지 않고 캐싱된 데이터를 사용한다.

stale-time의 default 값은 0이다. 즉 state-time을 설정하지 않은 데이터는 도착 즉시 최신이 아닌 상태가 되며, 쿼리 함수 호출마다 서버에게 새로운 fetch 를 요청하게 된다. react-query의 핵심은 개발자의 의도에 따라 캐싱을 통해 데이터의 요청을 제어하는 것이라 생각하기 때문에, 변경사항이 적은 데이터라면 반드시 stale-time 설정하는 것이 서비스의 이점이 된다.

cache-time

Query 상태가 4 → 5 로 변하는데 걸리는 시간을 의미한다.

해당 데이터를 사용하는 모든 컴포넌트가 unmount 된 경우, 해당 데이터는 inacvive 상태가 된다. cache-time은 inactive가 된 데이터를 캐시에서 완전히 삭제시키기까지의 시간을 설정하는 기능이다. 만약 cache-time이 유효하다면, 해당 시간 내에 데이터를 활성화하는 경우, 해당 캐시 데이터를 사용하게 된다.

stale-time 보다 cache-time을 길게 설정하라는 이유는 뭘까?

아마 stale-time > cache-time의 경우면, fresh 상태라 증명된 데이터가 삭제되기 때문일거라고 생각한다. stale-time < cache-time 의 경우, cache-time에 의해 캐싱이 되어있다고 하더라도, stale-time의 상태를 보고, 다시 fetch 를 통해 fresh 상태의 데이터를 가져올 수 있다.

효율적인 시간 범위 설정 방법은?

서비스를 어느정도 운영해봐야 알 수 있다고 생각된다. 서비스 프로세스나 사용자 수, 사용하는 기술, 서버 및 배포 환경에 따라 fetch와 캐싱 데이터를 사용 범위를 다르게 설정할 터이니 말이다.

일반적으로는 우선 20초, 5분의 설정을 유도하고 업데이트 마다 조금씩 변경하며 서비스에 효율적인 시간 범위를 찾는다고 한다.

profile
새로운 것에 관심이 많고, 프로젝트 설계 및 최적화를 좋아합니다.
post-custom-banner

0개의 댓글