WATCHAT 네트워크 요청 절감

오늘은 네트워크 요청을 줄이도록 코드를 리팩토링 했다. 

 

리스트 데이터 요청 관련 리팩토링인데, 기존에 데이터를 불러올 때는 알 수 없는 이유로 typescript의 타입 오류가 떠서 리스트 카드를 구성하는 요소들의 데이터를 따로 따로 불러왔다. 하지만 이러한 분산적인 데이터 요청은 네트워크 통신 비용을 증가시키기 때문에 리팩토링의 필요성이 있었다. 

 

아래 빨간 표시가 데이터를 따로 불러오는 부분이다. 

이 중 앞부분의 오너프로필을 통합하여 데이터를 요청하도록 해보았다. 

 

리팩토링 과정

1. 먼저 타입오류는 as type~~ 으로 타입을 강제적으로 변환시켜주는 과정을 거쳐서 고정시켜주었다. 
2. 데이터 요청 시에 외래키로 연결된 관련 테이블의 데이터도 함께 불러오도록 했다.
3. 관련 테이블의 데이터 중에서 내가 원하는 데이터만 가져오도록 조정하고
4. 기존에 위의 빨간 부분에서 분산적으로 불러오던 코드를 삭제하고 수정해주었다. 

  // 데이터 불러오기
  
  const response = (await browserClient
          .from('party_info')
          .select('*, team_user_profile!inner(*)')
          .range(startDataNumber(pageNumber), endDataNumber(pageNumber))
          .order(order, { ascending: false })
          .gte('end_time', nowTime())
          .textSearch('video_platform', platformConversion(filter))
  ) as PostgrestSingleResponse<partyAndProfiles[]>;

  // 분산된 데이터 불러오기가 2개에서 1개가 됨
  
  const { data: memberCount, isLoading: isCountLoading } = useMemberCount(data.party_id);

  // const { data: ownerInfo, isLoading } = useOwnerInfo(data);

 

개선 전 / 후

개선 이전 네트워크 요청

 

개선 후 네트워크 요청

 

이와 같이 네트워크 요청이 대폭 줄어든 것을 확인할 수 있다.

 

다만, 리팩토링 과정에서 다른 부분에서도 데이터 요청 병합을 진행했기 때문에 좀 더 크게 차이가 나게 보이는 것이다. 

 

 

 

향후 계획

네트워크 요청 병합은 이로서 일단락 된 것 같은데, 향후 과제에 대해서 좀 더 생각할 점이 있다. 나는 이번 리팩토링에서 분산된 데이터 요청을 완전히 병합하지는 않았는데, 그 부분이 사용자 이용에 따라 쉽게 변화하는 데이터이기 때문이다. 어차피 ssr로 리스트 데이터를 불러오기는 하지만, 이렇게 자주 변화할 수 있는 데이터를 어떻게 관리해야 하는지에 대한 의문이 들었다.

 

현재는 tanstack-query의 캐싱과 캐싱 무효화를 통해 이렇게 변화하는 데이터를 관리하지만, 네트워크 요청 병합과 합쳐서 이러한 문제를 어떻게 해결해야 하는지가 향후의 과제가 될 것 같다.