🧪 수많은 그래프 데이터 요청을 어떻게 줄일까

분야	작성자	작성일
FE	조배경	24년 12월 03일

너무 많은 요청

그래프를 살짝만 움직여도, 데이터가 와르르 요청됐다.

그래프를 왼쪽으로 스크롤 했을 때 데이터를 새로 트리거하는 것은 아래의 조건 뿐이다.

if (logicalRange?.from < 10 && hasNextPage) {
  fetchNextPage();
}

• 현재 보이는 영역의 시작점의 위치가 10보다 작고, 다음 페이지가 있다면 fetchNextPage를 실행한다.

차트 데이터가 없는 구간은 logicalRange.from이 전부 10보다 작다.

따라서 if문이 계속 true가 되어 데이터를 불러온다.

우선, 왜 중복 호출을 할까?

tanstack query의 특징으로는 queryKey를 기반으로 중복 요청을 방지하는 것인데, 왜 중복 요청이 발생할까?

내 생각은

1. useInfiniteQuery는 pageParam을 캐싱하고 있지 않거나
2. 요청이 완료되지 않은 상태에서 추가적으로 요청을 해서 중복처럼 보이는 것

이 아닐까 싶다. 실제로 tanstack query에서 데이터를 저장할 때는 중복을 허용하지 않는다.

1. pageParam 캐싱 여부

   1번 가설은 실제로 시간차를 두고 해당 구간을 요청해도 중복 요청이 가는지 판단해보면 알 수 있겠다.

   

   lastStartTime을 집중해서 보면 된다.

   처음에 데이터를 계속 요청할 땐 사용자의 스크롤이 너무 빠른 나머지 7월 3일자의 요청이 3번 간다. 다시 오른쪽으로 돌아와 누적된 데이터를 볼 때는 이미 불러왔던 데이터이기 때문에 7월 3일을 다시 부르지 않는다.

   즉, pageParam을 캐싱하지 않는다라는 것을 단정짓기보다는 데이터를 캐싱해두는 것은 맞다.

2. 요청이 완료되지 않은 상태에서 추가적으로 요청을 해서 중복처럼 보이는 것

   좀 더 자세히 살펴보기 위해 network를 slow 4G로 설정한 후 확인해봤다.

   하나의 요청이 pending 상태일 때 스크롤을 계속 한다면 동일한 api가 중복되어 요청되는 것을 확인할 수 있다.

   

즉, 사용자의 스크롤 속도가 데이터 패칭 속도보다 월등히 빨라서 다수의 요청이 생긴 것이다.

logicalRange의 범위 제한

그렇다면 logicalRange.from의 범위를 제한해보는 건 어떨까?

logicalRange?.from > 10 && logicalRange?.from < 11 

이 방법은 위험하다. 사용자가 얼마나 빨리 그래프를 스크롤 하느냐에 따라 from 값이 10~11 범위에 있을수도 있고, 없을 수도 있다!

운이 좋다면 저 범위 안에 들어가서 데이터를 패칭하겠지만, 그렇지 않은 아래의 경우도 있다. 😂

이렇게 되면 데이터를 불러오지 못한다.

그렇다고 범위를 넓게 지정한다면.. 또 다시 요청이 많이 보내질 것이다.

쓰로틀링을 적용해본다면?

짧은 시간동안 이벤트들이 연속해서 발생하므로, delay 단위로 그룹화하여 한번만 업데이트가 되도록 해보자.

스크롤을 통해 계속해서 요청을 한다면, isFetching 상태도 계속해서 변화할 것이다.

따라서 700ms 간격으로 업데이트되게 하여, 해당 값이 false일 때만 데이터를 트리거한다.

비유하자면 ‘요청 중’ 상태를 중간중간 블로킹 하는 느낌이다.

// isFetching의 변화를 쓰로틀링
// 700ms 간격으로만 throttledIsFetcing 값을 업데이트
const throttledIsFetching = useThrottle(isFetching, 700);

const fetchGraphData = useCallback((logicalRange) => {
 // throttledIsFetching이 false일 때의 조건 추가
  if (logicalRange?.from < 10 && hasNextPage && !throttledIsFetching) {
      fetchNextPage();
  }
}, [hasNextPage, throttledIsFetching, fetchNextPage]);

useEffect(() => {
  const chartInstance = chart.current;
  if (!chartInstance) return;

  const timeScale = chartInstance.timeScale();

  timeScale.subscribeVisibleLogicalRangeChange(fetchGraphData);

  return () => {
    timeScale.unsubscribeVisibleLogicalRangeChange(fetchGraphData);
  };
}, [chart, fetchGrahData]);

그 결과, 요청은 줄었다. 하지만 여전히 사용자가 빠르게 스크롤한다면, 동일한 lastStartTime 으로 중복 요청이 발생한다.

그 이유는 무엇일까?

만약 throttledIsFetching이 false로 업데이트 되기 전에 if문의 조건이 충족되는 경우를 생각해보자.

1. 데이터를 현재 요청 중이라서 throttledIsFetching이 true 라고 가정하자.
2. 이 상황에서 스크롤을 계속해서 700ms 안에 또 요청을 한다면, if문은 아직 참인 상태이기 때문에 fetchNextPage가 실행되고 만다. 즉, 스로틀링을 적용한 상태가 fetchNextPage를 완전히 제어하지 못한다.

또한 일정 시간 간격으로 상태를 업데이트할 뿐, fetchNextPage의 완료여부와는 무관하다. 네트워크 상황에 따라서 아직 요청이 완료되지 않았음에도 throttledIsFetching이 false가 될 수 있다. 따라서 서버와 클라이언트 간의 데이터 동기화 문제가 발생할 가능성이 있다.

만약 사용자가 더 빠르게 데이터를 원하는 경우에도, 원치 않은 지연이 발생할 수 있다.

그렇기 때문에 더 정확한 중복 호출을 막을 방법이 필요하다.

useRef를 이용하여 중복호출 막기

useInfiniteQuery의 isFetching의 경우엔, 요청이 한 개만 진행되는 것을 보장하지 않는다. 계속 스크롤로 데이터를 요청한다면, 이전 요청이 끝나기도 전에 isFetching의 상태가 계속해서 변화한다.

따라서 더 명확히 데이터 패칭 상태를 관리하기 위해서, 별도의 상태를 도입하기로 했다.

useRef를 사용하여 상태를 저장한다면 해당 상태에 대한 리렌더링은 막으며 API에 대한 중복호출도 막을 수 있을 것이다.

isPending 상태가 변경되었다고 해서 컴포넌트가 리렌더링이 될 필요가 없기 때문에 useRef를 사용하여 관리한다.

// pending 상태 저장
const isPending = useRef(false);

// 그래프의 가시 범위가 변경되면 실행되는 함수. 즉 스크롤하면 실행됨
const fetchGraphData = useCallback(
  async (logicalRange: LogicalRange | null) => {
    // 요청이 진행 중이라면 함수 종료
    if (isPending.current) return;
    
    // 그렇지 않다면 요청이 진행중
    isPending.current = true;

    if (logicalRange && logicalRange.from < 10 && hasNextPage) {
      await fetchNextPage();
    }
	
    // 요청이 끝나면 false로 설정
    isPending.current = false;
  },
  [hasNextPage, isFetching, fetchNextPage],
);

// 이전과 동일
useEffect(() => {
  const chartInstance = chart.current;
  if (!chartInstance) return;

  const timeScale = chartInstance.timeScale();
  timeScale.subscribeVisibleLogicalRangeChange(fetchGraphData);

  return () => {
    timeScale.unsubscribeVisibleLogicalRangeChange(fetchGraphData);
  };
}, [chart, fetchGraphData]);

• fetchGraphData는 그래프의 가시 범위가 변경되면 호출되는데, 이때 isPending 플래그를 통해 중복 요청을 방지한다.
• async/await로 fetchNextPage 호출 시 해당 작업이 완료될 때까지 기다린다. api 응답 완료 전에 isPending.current가 false로 실행하는 것을 방지한다.

레퍼런스

Debounce(디바운스) - JavaScript에서 함수를 지연시키는 방법 (JS ES6 예제)

리액트 애플리케이션에서 API 중복 호출을 정확히 막는 방법