메모리에 있지 않은 데이터 캐시처리 이후

음식탭을 주루르르르륵 한참 내리다가 선택을 하면

레스토랑 디테일로 갔다가

바로 레스토랑 탭으로 갑니다.

그럼 레스토랑 탭에는 기존에는 없던 새로운 레스토랑이 추가가 됩니다.

이제 여기서 paginate를 합니다.

그럼 새롭게 추가된 레스토랑의 id이후로 fetchCount를 가져올텐데

기존 20개 추가된 1개 사이에 몇개는 누락되어서 서버에서 전달되어 오지 않을까 해서요 !

마지막 추가된 1개 이후의 개수만 가져오니까요

 ex)

원래 서버에 있는 레스토랑 개수는 10개 라고 치면

기존에는

id: 1 , 2, 3, 4 가 있었고 새롭게 추가된게 id 8번이면

8번 이후로 fetchCOunt만큼 가져와 했을떄 9,10,11을 가져오지

5,6,7번을 누락되는 것이 아닐까? 싶었습니다.

안녕하세요!

무슨 말씀이신지 이해했습니다.

말씀하신 부분 문제가 될 수 있습니다.

그래서 저같은경우 프로젝트가 복잡해지고 다양한 요구사항이 생길수록 캐시를 완전 중앙화하거나 관련기능별로 나눕니다.

제가 강의에서 보여드린 캐시 관리 방법의 주요 포인트는 A 모델과 A의 상세 모델을 같은 캐시로 관리했을때 쉽게 동기화되는 장점이 있다는 겁니다.

말씀하신 상황처럼 캐시관리가 복잡해져야하는 경우 추가적인 시스템이 필요합니다.

저같은경우 아예 캐시 키를 직접 입력해서 배정하는 방식을 사용하는 경우가 많습니다.

이렇게 할 경우 같은 A 모델이라도 따로 관리가 가능해집니다. 예를들어 A1, A2... 등등으로 가능합니다.

또는 데이터 캐시와 순서 캐시를 따로 관리하는 방법도 있습니다. 예를들어 PostModel에 대한 캐시는 모두 하나의 Map으로 들고 있고 리스트를 보여줘야하는 페이지별로 따로 ID의 순서만 들고 있으면서 GET 요청이 있을때 ID 순서대로 모델을 재구성하는 방법입니다.

여기서 더 발전하면 Optimistic Response, Throttling, Debounce도 쉽게 해결 할 수 있는 통합 API를 구축 해볼수도 있습니다.

다만 상당한량의 코드와 예외처리가 필요하기 때문에 조금 난이도가 있습니다.

쉽게 해결 할 수 있는 방법중 하나는 음식탭에서 상세를 들어갔을때는 캐시를 아예 따로 관리하는 방법입니다 (프로바이더 아예 따로 생성).

이럴경우 두 캐시가 서로 혼합되지 않기 때문에 문제가 생기지 않습니다.

감사합니다!