TIL - 효율적인 데이터 Fetching 전략: 벌크 vs 개별 요청

데이터 Fetching의 중요성

1. 사용자 경험(UX) 향상:

• 빠르고 효율적인 데이터 로딩은 사용자 만족도를 크게 높입니다.
• 지연 시간을 최소화하여 앱의 반응성을 개선합니다.

2. 성능 최적화:

• 불필요한 데이터 전송을 줄여 네트워크 대역폭을 절약합니다.
• 서버 부하를 감소시켜 전체 시스템의 효율성을 높입니다.

3. 리소스 관리:

• 클라이언트와 서버 모두의 리소스(메모리, CPU 등)를 효율적으로 사용합니다.
• 모바일 기기에서 특히 중요한 배터리 소모를 줄일 수 있습니다.
  
  
  

벌크 요청 방식 (getMultipleTrackDetails)

구현 방법:

Spotify API를 사용하여 벌크 요청을 구현하는 예시

async getMultipleTrackDetails(trackIds: string[]): Promise<SpotifyApi.TrackObjectFull[]> {
  const access_token = await this.getAccessToken();
  const ids = trackIds.join(',');

  const response = await fetch(`https://api.spotify.com/v1/tracks?ids=${ids}`, {
    headers: { Authorization: `Bearer ${access_token}` },
  });

  const data = await response.json();
  return data.tracks;
}

 

사용 예시:

const tracks = await api.spotify.getMultipleTrackDetails(['id1', 'id2', 'id3']);

 

장점:

• 단일 네트워크 요청으로 여러 트랙의 정보를 한 번에 가져올 수 있어 효율적입니다.
• 서버 부하를 줄일 수 있습니다.
• 구현이 간단하고 직관적입니다.
• 전체 데이터를 한 번에 로드하므로 UI 렌더링이 일관적입니다.

단점:

• Spotify API에서 한 번에 가져올 수 있는 트랙의 수에 제한이 있을 수 있습니다.
• 모든 트랙 정보가 한 번에 로드되므로, 일부 트랙 정보만 필요한 경우에도 불필요한 데이터를 가져올 수 있습니다.
• 대량의 데이터를 한 번에 로드하므로 초기 로딩 시간이 길어질 수 있습니다.

 

개별 요청 방식 (useQueries with getTrackDetails)

API 함수

각 트랙을 개별 요청으로 가져오는 예시

async getTrackDetails(trackId: string): Promise<SpotifyApi.TrackObjectFull> {
  const access_token = await this.getAccessToken();

  const response = await fetch(`https://api.spotify.com/v1/tracks/${trackId}`, {
    headers: { Authorization: `Bearer ${access_token}` },
  });

  return response.json();
}

 

클라이언트 컴포넌트에서 사용

클라이언트에서 여러 트랙을 병렬로 요청하는 방법

import { useQueries } from '@tanstack/react-query';

function TrackList({ trackIds }) {
  const trackQueries = useQueries({
    queries: trackIds.map(id => ({
      queryKey: ['track', id],
      queryFn: () => api.spotify.getTrackDetails(id),
    })),
  });

  // 결과 처리
  const tracks = trackQueries.map(query => query.data).filter(Boolean);

  // ... 렌더링 로직
}

 

장점:

• 필요한 트랙 정보만 선택적으로 가져올 수 있어 유연성이 높습니다.
• 각 트랙에 대한 요청을 개별적으로 캐싱하고 관리할 수 있어, 재사용성이 높습니다.
• 동시에 여러 요청을 병렬로 처리할 수 있어 전체 로딩 시간을 줄일 수 있습니다.
• 부분적인 데이터 로딩이 가능해 progressive loading을 구현하기 쉽습니다.

단점:

• 많은 수의 트랙을 가져올 때 여러 번의 네트워크 요청이 발생하여 서버 부하가 증가할 수 있습니다.
• 구현이 약간 더 복잡할 수 있습니다.
• 각 요청이 개별적으로 실패할 수 있어 에러 처리가 더 복잡해질 수 있습니다.
• 네트워크 상태에 따라 일부 트랙 정보만 로드되어 UI가 일관적이지 않을 수 있습니다.

 

선택 기준:

• 데이터의 양: 트랙 수가 적다면 벌크 요청이, 많다면 개별 요청이 유리할 수 있습니다.
• 사용 패턴: 항상 전체 목록이 필요하다면 벌크 요청이, 부분적 로딩이 필요하다면 개별 요청이 적합합니다.
• 캐싱 요구사항: 개별 트랙 정보를 자주 재사용한다면 개별 요청 방식이 유리합니다.
• 성능 요구사항: 초기 로딩 속도가 중요하다면 벌크 요청이, 점진적 로딩이 중요하다면 개별 요청이 좋습니다.
•  

결론: 상황에 맞는 유연한 접근의 중요성

오늘 배운 것 중에서 가장 중요한 점은, 데이터 fetching은 현대 웹 애플리케이션의 핵심 요소이며, 효율적인 데이터 fetching은 애플리케이션의 성능, 사용자 경험, 확장성에 직접적인 영향을 미친다는 것입니다. 하지만 모든 상황에 적용할 수 있는 단일 "최고의" 솔루션은 없다는 것을 배웠습니다. 따라서 다양한 전략을 이해하고, 각 상황의 특성과 요구사항을 고려하여 가장 적합한 접근 방식을 유연하게 선택하고 적용할 수 있어야겠다고 생각했습니다.