onSettled 질문드립니다.

작성한 질문수 27

0

안녕하세요 나마스테님 이정환입니다

우선 말씀하신대로 onSettled 에서 invalidateQueries를 호출하므로 데이터의 용량이 커지면 부하가 발생하는 것은 맞습니다. 그러나 이는 낙관적 업데이트에서 필수적인 사항입니다.

낙관적 업데이트는 서버의 응답을 기다리지 않고 "아마 이렇게 수정되었을 것이다" 혹은 "요청이 무조건 성공했을 것이다" 라고 예상해 캐시 데이터를 미리 바꿔놓습니다. 그러나 캐시 데이터가 실제 서버의 데이터와 100% 일치할 것이라고 보장할수는 없기에 onSettled 에서 실제 서버의 데이터로 교체하기 위해 캐시를 무효화 시켜주고 있는 것 입니다. 이 방식은 Tanstack Query의 공식 문서 예제에도 소개되어 있으며 실무에서도 실제로 자주 사용되는 패턴입니다.

다만 정말 데이터가 커서 부담이 된다면 실무에서는 다음과 같이 해결하기도 합니다.

• 프론트엔드에서 요청 발생시 일단 onMutate로 낙관적 업데이트

• 백엔드가 API Response로 결과로 생성된 데이터를 함께 반환

• 프론트엔드 측에서는 성공 실패 여부에 따라 다음과 같이 동작

  • onSuccess시 백엔드가 반환한 데이터로 캐시를 맞춤 (setQueryData)

  • onError시 기존의 캐시 데이터로 원복 (요청 이전으로)

위와 같이 설정하면 리스트 전체를 다시 불러오지 않고도 서버의 데이터와 캐시 데이터를 일치시킬 수 있습니다. 다만 구현의 복잡함이 뒤따르고 또 다른 클라이언트의 요청으로 인한 변경 사항은 반영되지 않기 때문에 상황에 따라 적절히 선택해야 할 것 같습니다.

0

안녕하세요, 인프런 AI 인턴입니다. 나마스테님

onSettled에서 invalidateQueries를 호출하면 mutation의 성공·실패 여부와 관계없이 관련 쿼리를 무효화하고 서버에서 최신 데이터를 다시 요청하게 됩니다. 따라서 데이터가 많거나 요청 빈도가 높은 경우에는 네트워크 요청과 서버 부하가 발생할 수 있습니다.

다만 강의의 onSettled는 낙관적 업데이트 이후 서버의 실제 데이터와 캐시를 최종적으로 동기화하기 위한 안전장치입니다.

• onMutate: 화면에 변경 내용을 먼저 반영
  
• onError: 실패 시 이전 캐시 데이터로 롤백
  
• onSettled: 성공·실패 후 서버 데이터와 최종 동기화
  

실무에서는 상황에 따라 다르게 적용합니다.

• 데이터 정합성이 중요하거나 서버에서 최종 결과가 달라질 수 있으면 invalidateQueries 사용
  
• 변경된 데이터가 명확하고 응답값을 신뢰할 수 있으면 setQueryData로 해당 캐시만 직접 수정
  
• 전체 목록이 아니라 특정 데이터만 변경되었다면 관련된 쿼리만 선택적으로 무효화
  
• 데이터 구조가 복잡해지면 캐시 정규화 전략을 사용
  

즉, onSettled의 invalidateQueries가 항상 잘못된 방식은 아니지만, 데이터 규모와 요청 빈도가 커지면 불필요한 전체 재요청이 될 수 있습니다. 강의의 다음 정규화 관련 내용에서는 이러한 문제를 줄이기 위한 방법을 다룹니다.

관련 질문을 함께 참고해 보세요.

• 캐시 데이터 다루기 - 낙관적 업데이트(2)에서 질문
  
• onSettled와 setQueryData
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.