RN 캐싱관련 질문입니다.

안녕하세요. 초보 학생 개발자 입니다.

현재 리액트 네이티브에서 무한스크롤로 데이터를 받아와 리스트에 무한히 뿌려져 있고, 이 데이터는

이미지 url + 스트링 값들로 이루어져 있습니다.

그런데 한번 로드했음에도 불구하고 앱에 재 접근시 또 이미지와 데이터를 로드하는 것은 매우 비효율 적이고 비용이 많이 든다고 생각하여

캐싱을 해보려고 합니다.(경험은 없습니다 ㅜ)

그런데 이 데이터들을 mutable합니다. 변경될 가능성이 있습니다. (높진 않습니다만 인스타그램 feed와 비슷한 상황입니다.)

이러한 데이터들을 캐싱을 하고싶은데 변경점 파악을 서버에 항상 물어야하는건가요?? 보통 이런상황일때 전반적인 해결방법이 궁금합니다.

제가 생각한 플로우는

  1. 최초 데이터를 10개 받아옴

  2. 스크롤 end에 도달하면 api에 타임스탬프 기준으로 변경사항이 있는지 물어봄.

  3. 변경사항이 있다면 그 데이터를 가지고 스토어 배열을 돌면서 데이터 교체를 해줌

  4. 변경사항이 없다면 새로운 데이터를 스토어 리스트에 추가함

이런 식으로 생각해보았는데 맞는 방법인지, 통상 어떤식으로 하는지 궁금합니다. 저는 초보라 그런지 완벽한 표준은 없지만 약간의 표준?이 늘 궁금하네요.

그리고 persist store에 데이터를 저장을 하다보면 데이터가 엄청 커질꺼 같은데 이런것은 해결을 어떻게 하나요? 인스타그램도 sqlite에
저장하는것 같던데 궁금합니다.

ps: persist store에 저장하는 것은 캐싱이라 볼 수 없나요?

cache는 크게

  • 서버사이드에서 이 컨텐츠의 cache를 이렇게 관리하라고 알려주는 부분과
  • 클라이언트 사이드에서 실질적으로 캐시를 관리하는 방법
    으로 나뉩니다.

서버사이드의 http응답에 들어 있는 캐시정보는 말그대로 참고용으로 클라이언트 사이드가 무시하면 아무 소용은 없습니다만 대부분의 클라이언트들의캐시관리 기본 설정이 이 서버사이드의 정보를 바탕으로 할겁니다.

저는 RN에서 좀 더 공격적인 Image 캐시를 하고자 할 경우 <FastImage>를 사용하고 있습니다. 한가지 주의할 점은 이미지의 개수와 사이즈가 클 경우 저사양 폰에서 앱이 죽는 경우가 있습니다. 제 경우에는 서버에서 리사이징한 이미지를 이용하면 큰 문제는 없었습니다.

위에서 설명한 부분이 혹시 같은 이미지 url인데 변경될 가능성이 있다는 얘기인가요?

따로 저장해뒀다가 다시 가져오지 않고 쓰면 모두 캐시라할 수 있죠. :slight_smile:

다음 링크도 한번 살펴보세요.

1개의 좋아요

데이터를 가져오는 것이 보통은 몇kb 정도죠. 이런 일반적인 상황에 서버나 네트웍에 거의 무리가 가지 않습니다.
데이터가 수십만 건이라거나 해서 진짜 무리가 되는 상황에 캐시를 고려하는게 좋습니다.

로직의 복잡성이 부담(개발시간, 버그, 향후 변경 등)이 되는데, 그 복잡성이 일반적인 상황에서 서버나 네트워크 부하보다 훨씬 큽니다.
특히 sqlite 등을 사용해서 local의 persistant한 곳에 캐싱을 하기 시작하면 복잡도가 너무 커집니다.

이미지는 용량이 크고 전송비용을 생각해야 하니 이종은님이 추천하신 뷰를 통해서 캐싱하시면 좋겠네요.

엔지니어 적으로 이미 동일한 데이터를 다시 가져오는데 거부감이 들순 있지만, 간결한 로직으로 개발속도와 유지보수 편의성을 얻는 것이 더 중요하다고 생각해요.
물론 공부하는 입장에서는 캐싱을 해볼만 합니다 :slight_smile:

3개의 좋아요

네 감사합니다!

persist-store를 살짝 이용해서 최대한 데이터를 줄이는 방향으로 정했습니다.

완벽한 캐싱 구현은 제 실력이 부족하여 힘들것 같네요 ㅠ ㅜ 시간도 문제구요 ㅎㅎ ㅜ

답변감사합니다~~

FastImage를 한번 써봐야겠네요.

캐싱 size? 관리같은건 자동으로 되는건가요?? 거기에 관한 설명은 문서에서 없는것 같은데 궁금합니다

동우님의 이 말씀 실전에서는 아주 중요한 부분이라 생각합니다. :slight_smile:

1개의 좋아요