Address 컴포넌트 캐싱 전략 구현

[hyeone22]

Address 컴포넌트 캐싱 전략 구현

수정 이유

• 주소 데이터가 자주 변경되지 않는 정적 데이터임에도 불구하고 매번 API 호출 발생
• 마이페이지에서 주소 수정 시에만 데이터가 변경되는 특성을 고려하지 않은 구조
• 불필요한 API 호출로 인한 성능 저하 발생

고민 과정

• 처음에는 영구 캐싱(Infinity)을 고려했으나, 메모리 관리 측면에서 부적절하다고 판단했습니다.
• 대신 서비스 특성을 고려하여 staleTime은 1시간, gcTime은 24시간으로 설정했습니다.
• 마이페이지에서 주소 수정 시 즉시 캐시를 무효화하기 위해 mutation 성공 시 invalidateQueries를 호출하도록 구현했습니다.

1. 캐싱 전략 선택

• 영구 캐싱 vs 적절한 시간 설정
• Infinity 설정은 메모리 관리 측면에서 부적절
• 서비스 특성을 고려한 적절한 캐시 시간 설정 필요

2. 캐시 무효화 시점

• 마이페이지에서 주소 수정 시 즉시 캐시 무효화 필요
• mutation 성공 시 invalidateQueries 호출로 해결

3. 시간 설정

staleTime: 1000 * 60 * 60, // 1시간 동안 fresh 상태 유지
gcTime: 1000 * 60 * 60 * 24, // 24시간 동안 가비지 컬렉션 전까지 캐시 유지

성능 개선 결과

• 불필요한 API 호출 감소 (페이지 진입마다 발생하던 API 호출이 1시간 동안 캐시된 데이터 사용)
• 캐시된 데이터 즉시 사용으로 렌더링 지연 시간 감소
• 데이터 즉시 표시 및 주소 수정 시 즉각적인 UI 업데이트로 사용자 경험 향상

API 호출 감소

• 기존 : 페이지 진입마다 API 호출 발생
• 개선 : 1시간 동안 캐시된 데이터 사용
• 결과 : API 호출 횟수 감소

렌더링 성능

• 기존 : API 응답 대기로 인한 렌더링 지연
• 개선 : 캐시된 데이터 즉시 사용으로 렌더링 시간 단축
• 결과 : 초기 렌더링 시간 단축

사용자 경험

• 데이터 즉시 표시로 인한 UX 향상
• 주소 수정 시 즉각적인 UI 업데이트
• 불필요한 로딩 상태 제거

추가 고려사항

• 캐시 시간은 서비스 상황에 따라 조정 가능
• 네트워크 상태에 따른 캐시 전략 최적화 필요
• 추후 오프라인 지원을 위한 캐시 전략 확장 고려