Apollo client cache

🗣 먼저, Apollo Client를 사용하는 이유

1. graphQL를 사용중이다. ⇒ graphQL과 연동을 쉽게 도와주는 라이브러리이기 때문
2. 기본적으로 브라우저캐시는 GET 요청만 캐싱하는데, graphQL은 모든 요청을 POST하므로, 브라우저 캐시를 사용할 수 없기 때문에 Apollo client를 사용한다.

캐시란, 데이터를 임시로 저장해두는 곳

나는 hooks를 사용해서 useQuery로 데이터를 불러오는 방법을 이용하고있다. 왜냐하면 코드도 간결해지고, loading, error, refetch, data 등을 제공해줌으로써 에러핸들링, 상태처리, 재요청 등을 간결하게 처리할 수 있다.

    const { loading, error, refetch, data } = useQuery(Queries.TEMP_DATA, {
        fetchPolicy: 'cache-and-network'
      });

앞서 이야기했던 것처럼, graphQL 서버에 요청 시 모든 요청이 POST로 가기 때문에, GET 요청만을 처리하는 브라우저 캐시를 사용할 수 없다. Apollo client cache를 사용함으로서 단순히 캐시를 사용할 수 있는 것을 넘어서 다양한 기능을 제공한다.

📌 Apollo client cache 동작 원리

1. 각각의 요청별로 캐싱
2. 응답 데이터를 분리하여 재구조화하여 자동으로 cache data를 업데이트 사실 이 부분에 대해서 와닿지 않음.
3. 로컬 상태 관리
   1. 로컬 상태를 직관적으로 관리할 수 있다. @client 키워드를 붙여주는 것 이외에 서버에 요청보내는 문법이 같다. ⇒ 변수명 약속을 만들면 유지보수에 쉽다!
4. 위 코드에서 fetchPolicy에 해당하는 다양한 cache 옵션을 제공한다. 이 옵션은 각각의 요청마다 다르게 적용할 수 있고, 각각의 요청에 적절한 옵션을 선택한다면 효율적으로 동작할 수 있다.

이 글에서는 cache 옵션에 좀 더 자세히 적어보려한다.

🗣 cache 옵션 (fetchPolicy)

fetchPolicy를 통해 데이터 캐시와 상호 작용하는 방식을 지정할 수 있다. 캐시에서 읽기를 시도하고 쿼리의 데이터가 캐시에 있으면 Apollo는 단순히 캐시에서 데이터를 반환한다. 쿼리의 전체 데이터가 캐시에 없으면 Apollo는 네트워크 인터페이스를 사용하여 요청을 실행한다.

🤭cache-first 항상 캐시를 먼저 확인한다. 캐시가 데이터에 없다면 network 요청을 보낸다.

🤭network-only 캐시에서 초기데이터를 반환하지 않고 항상 network 요청을 보낸다.

🤭cache-only 캐시만 확인한다. 캐시에 데이터가 없다면 에러를 반환한다.

🤭cache-and-network 먼저 캐시를 확인하여 데이터를 반환한다.(업데이트 되지 않은 데이터일지라도) 이후 network요청을 하여 새로운 데이터를 받아와 캐시를 업데이트하고, 업데이트된 캐싱 데이터를 다시 반환한다.

🤭no-cache 캐시를 확인하지 않고 항상 network 요청을 보낸다. network-only 정책과 달리 쿼리가 완료된 후 캐시의 데이터를 읽지 않는다.