데이터 패칭

데이터 패칭

• 내장 브라우저 API (Fetch API)

• 단순 프로미스 기반 HTTP 클라이언트 (Axios)

• 쿼리 라이브러리 (Tanstack Query, SWR)

Fetch API와 Axios는 다소 유연하지만 저수준,

에러 핸들링, 에러 캐치, 재시도 등 반복적인 코드를 작성해야함

많은 복잡성을 추상화하여 제공하는 세련된 라이브러리들이 나타남 (Tanstack Query)

Tanstack Query

캐싱

가져온 데이터를 저장해둠

• 캐싱 프로세스를 서버 혹은 브라우저 로컬 저장소가 아닌 메모리(자바스크립트 객체/스토어)를 사용하여 직접 관리

• 데이터를 가져오면 캐시에 자동으로 저장됨

• 캐시에서 데이터를 가져오는 것과 함께 백그라운드에서 네트워크 요청을 만들어 사용자의 시각적 로딩 시간을 현저히 줄임

• staleTime 값이 설정된 경우 백그라운드에서 네트워크 요청을 하지 않고 캐시 데이터를 사용함

캐시 업데이트

캐시와 직접 상호작용하고 캐시를 업데이트 할 수 있다.

• 변경 요청을 성공 및 실패했을 때 캐시를 업데이트하고 싶을 수 있음

• setQueryData 함수를 사용하면 쿼리 키를 기반으로 특정 쿼리의 캐시를 업데이트 가능

• 추가적인 가져오기 요청이 없어도 낙관적 업데이트를 제공

• Important Defaults

• Caching

데이터 미리 가져오기

데이터가 실제 필요하기 전에 적극적으로 가져오는 프랙틱스

• 사용자가 UI 요소와 상호작용하거나 새로운 페이지로 이동했을 때 최신 데이터를 바로 사용할 수 있도록 미리 준비

• 인지된 로딩 시간을 줄여 매끄러운 사용자 경험을 제공

• prefetchQuery

  • 지정한 쿼리키에 관한 데이터를 미리 가져옴

  • 이후 같은 쿼리 키를 사용해 useQuery를 호출하면 네트워크 요청 없이도 캐싱된 데이터에 즉시 접근 가능

  • 이벤트 핸들러에 의해 트리거 될 수 있음

  • 라이프사이클, 페이지 이동하기 전에도 트리거 가능

플레이스홀더 데이터

쿼리 데이터가 아직 요청 중인 경우 플레이스홀더 데이터가 있다면 해당 데이터를 사용자에게 보여줌

• 느린 네트워크 요청을 다룰 때

• 낙관적인 업데이트를 제공할 때

• 일관성 있는 레이아웃을 보장할 때

• placeholderData 옵션을 사용하여 표시

  • 캐시에 초기 데이터를 저장하지 않고도 해당 데이터로 사용자에게 표시

  • 플레이스홀더 및 캐시에 저장하고 싶다면 initialData 쿼리 옵션 사용하면됨

재시도 메커니즘

요청이 실패하는 경우 해당 쿼리를 재시도(기본 3) 후 에러를 표시

• retry 옵션

  • true로 설정할 경우 무한 재시도

  • 일반적으로 특정 횟수만큼 재시도하도록 설정

• 앱이 간헐적으로 네트워크 이슈를 가질 수 있는 경우, (특정 요청이 다른 쿼리 요청보다 자주 실패할 것으로 예상될 때)

그 외 기능들

• 의존 쿼리: 한 쿼리의 완료 상태에 따라 다른 쿼리를 실행 가능 (데이터 패칭을 순서대로 해야하는 경우)

• 병렬 쿼리: 여러 쿼리를 동시에 패칭 가능

• 페이지네이션 및 무한 쿼리

• 서버 렌더링 및 수화 지원

효율적인 데이터 패칭 팁

앱이 커지면 데이터 패칭 프로세스 최적화 전략을 마련하는것이 중요

• 최적의 리소스 활용 보장 및 보다 나은 사용자 경험 제공

• 앱의 데이터 니즈와 함께 앱의 데이터 소스의 성능 특성에 관해서도 심사숙고 해야함

• 데이터 모델을 세심하게 설계하는 것

  • 데이터 소스의 수를 최소화

  • 데이터 저장과 회수를 최적화

  • 확장성을 염두에 두고 데이터 모델 설계

  • 이와 관련된 작업들은 모두 서버 DB 측에서 이뤄짐

  • 최적화된 서버 사이드 구조는 필연적으로 클라이언트 사이드의 데이터 패칭 프로세스를 단순하게함

• 엔드포인트 최적화

  • DB 인덱스 효과적으로 활용하기

  • DB 호출 횟수 줄이기

  • 서버 응답 압축하기

  • 서버 사이드에서의 응답 데이터 필터링 및 제한하기

• 가능하다면 요청을 배치로 만들어라

  • 여러 작은 요청을 하나의 배치 요청으로 합치면 개별 요청에 의해 발생하는 오버헤드를 줄일 수 있음

  • 특정 데이터셋이 짧은 간격으로 계속해서 요청된다면 활용

  • 전체적인 지연과 처리시간을 줄임

• 우선순위를 지정하고 요청을 연기

  • 가져올 데이터와 가져올 시기를 신중히 결정하는 것은 앱의 응답성을 유지하는데 매우 중요

  • 페이지를 로딩할 때 모든 데이터를 즉시 가져올 필요 없음

  • 초기 사용자 경험에 중요한 데이터가 무엇인지 식별하고 그 데이터를 먼저 가져와라

  • 즉시 필요하지 않은 데이터라면 지연 로딩 사용을 고려

• 지연 로딩을 사용

  • 많은 양의 데이터를 다루는 경우 지연 로딩을 사용하면 페이지의 초기 로딩 시간을 상당히 개선 가능

  • 브라우저는 최초 꼭 필요한 최소한의 컨텐츠만 가져와서 렌더링하면 되기 때문

• 캐싱을 사용해 데이터 가져오기 최소화

  • 적절한 캐시 만료시간 사용

  • 자주 접근되는 데이터만 캐싱

  • 캐시 무효 전략 구현

• GraphQL 사용 고려

  • REST 접근법보다 효율적, 유연하고 강력한 대안 제공

  • 여러 엔드포인트를 사용하는 대신 내가 필요한 데이터만, 필요한 형태로, 단일 엔드포인트에 요청 가능

  • 클라이언트 관점에서 많은 이익을 제공하지만 만능은아님

  • GraphQL 서버를 설정하는것은 REST 엔드포인트를 사용할 때는 잘보이지 않는 성능 오버헤드를 야기하기도함