Understanding Caching in Apollo Client 3
위의 강의와 블로그 포스팅을 정리한 글입니다.
잘못된 내용이 있을 경우 언제든지 지적 부탁드립니다.
들어가기전에
위와 같은 단어들의 정의을 알고
가능한 최고로 효율적인 방법으로 캐시를 사용하기 위해 API를 올바르게 사용하는 방법을 알자.
기본적으로 Apollo는 in-memory-cache 저장소를 사용합니다.
따라서 세션에 요청한 데이터가 저장되지 않습니다.
정규화
쿼리 요청 결과는 캐싱되기 위해 정규화 됩니다.
그리고 정규화된 캐시 데이터는 불필요한 네크워크 요청을 피하기 위해서 사용됩니다.
위의 이미지에서 보면 캐시된 데이터가 있고 Apollo가 그 위에 개발자들이 캐시와 상호작용 하기 위해 사용할 API 레이어를 구축한다는것을 알 수 있습니다.
데이터 정규화는 데이터 중복을 줄이기 위해 데이터베이스를 구성하고 구조화하는 프로세스입니다.
간단히 말해서, 데이터 베이스 정규화 프로세스는 모든 필드와 레코드가 논리적으로 구성되어
중복을 방지하고 관계형 데이터베이스를 보다 효율적으로 사용하도록 하는 방법입니다.
위와같은 관계형 DB에는 테이블이 있고 각 테이블에는 일반적으로 PK와 FK가 있습니다.
이는 서로간의 테이블을 연결시킴으로서 같은 데이터를 다른 테이블에 복제하고 싶지 않기 때문입니다.
이와 유사한 일이 아폴로 캐시저장소 내부에서 발생합니다.
우리는 graphql 데이터를 원하고 중복되지 않는 유일한 객체 데이터를 원합니다.
관계가 있는 중복된 데이터일경우 캐시에 중복된 데이터가 저장되지 않길 바랍니다.
apollo 캐시 저장소에서는 요청하고 응답받은 graphql 데이터에 대해 이러한 정규화를 달성하기 위한 일련의 과정이 수행됩니다.
Apollo client의 InMemoryCache는 데이터를 flat lookup table 형태로 저장합니다.
따라서 객체 안에서 각각을 서로 참조할 수 있습니다. 이 객체는 GQL 쿼리에서 리턴받는 객체와 일치합니다.
따라서 여러 쿼리를 하더라도 하나의 객체로 묶여져서 캐싱됩니다.
캐시는 플랫하지만, GQL 쿼리로 응답 받은 객체는 플랫하지 않을 수 있습니다.
{
"data": {
"person": {
"__typename": "Person",
"id": "cGVvcGxlOjE=",
"name": "Luke Skywalker",
"homeworld": {
"__typename": "Planet",
"id": "cGxhbmV0czox",
"name": "Tatooine"
}
}
}
}위의 응답은 data 안에 Person 객체가 있고 그 안에 Planet 객체가 존재합니다.
이렇게 중첩된 데이터를 플랫하게 캐시에 저장해주어야 하는데, 이러한 과정에서 사용되는 방법이 정규화 입니다.
apollo client 캐시가 쿼리 데이터를 받으면 다음과 같은 과정들을 수행합니다.
- 객체를 확인한다(identify objects)
- 캐시는 쿼리의 응답에 포함된 고유 객체를 식별합니다.
- 캐시 ID를 만든다(Generate cache IDs)
- 캐시는 식별된 각 객체에 대한 캐시 ID를 생성합니다.
- 생성된 캐시 ID는 In-Memory-Cache에 있는 특정 객체를 고유하게 식별합니다.
- 캐시 ID는 객체의 _typename과 ID 필드를 콜론으로 구별합니다.
- 특정 객체 유형에 대한 캐시 ID 형식을 사용자 정의할 수 있습니다.
- 객체의 필드를 레퍼런스로 대체한다.(Replace object fields with references)
1. 캐시는 객체가 포함된 각 필드를 가져와 해당 객체에 대한 참조로 값을 바꿉니다.
n-static.com/8b7b22a9-7a56-40c7-88bf-235d712f5a31/Untitled.png)
- 정규화된 객체를 저장한다.
- 결과 객체도 모두 캐시의 flat lookup 테이블에 저장됩니다.
