서론
다니고 있는 회사에서 메인 서버와의 통신은 GraphQL + Apollo를 이용하고 외부 써드파티(AWS serverless)와의 통신에 REST + Axios를 이용하고 있었다.
GraphQL, REST, Caching
GraphQL은 REST와 다르게 하나의 엔드 포인트로 클라이언트에서 작성한 쿼리에 맞춰 오직 POST 메서드로 요청이 가고 원하는 응답을 받을 수 있게 해주는 쿼리 언어이다.
REST는 여러 가지의 엔드 포인트를 가지고, 각 엔드 포인트의 요청이 고정적인 구조를 가지고 있어 이를 지켜서 요청해야 하고 요청에 따른 고정적인 리소스를 수신하게 된다.
이런 엔드 포인트 기반이기 때문에 HTTP Caching을 사용할 수 있지만, 하나의 엔드 포인트를 사용하는 GraphQL은 HTTP Caching 전략을 사용할 수가 없다.
대신, GraphQL은 별도로 in-memory cache를 로컬에 저장하는 기능을 제공한다.
이 기능은 캐싱된 데이터에 대해 요청을 할 때 네트워크 요청없이 매우 빠른 속도로 응답 결과를 수신할 수 있게 해준다.
더해서, 캐싱 기능을 위한 Configuration 또한 매우 간단하다.
Fetch Policy
캐싱을 할지 말지, 캐싱된 데이터를 사용할 것인지 말지, 케싱된 데이터를 우선 사용하고 응답이 오면 응답 결과 데이터를 사용할 것인지, 이러한 옵션들을 모두 Fetch Policy를 통해 정할 수 있다.
Apollo-Client에서 데이터를 요청할 때 쓰이는 훅인 useQuery 또는 useLazyQuery에서 fetch policy를 다음과 같이 지정할 수 있다.
const { data } = useQuery(GET_TODOS, {
fetchPolicy: 'network-only',
}Fetch Policies
fetch policy는 여러 가지가 있는데 다음과 같다.
| 이름 | 설명 |
|---|---|
cache-first | 첫 요청이 캐시만 거쳐서 응답을 먼저 가져온다. 만약 요청된 모든 데이터가 캐시에 동일하게 존재하는 상태라면 해당 데이터를 반환한다. 앞과 같은 상태가 아니라면, GraphQL Server로 쿼리 요청을 실행하고 응답 결과를 동일한 상태로 캐시에 업데이트하고 이를 반환한다. fetch policy를 따로 설정하지 않는다면, 기본값을 적용된다. |
cache-only | 오직 캐시만을 거쳐서 가져온다. 절대 서버로 요청을 날리지 않는다. 요청된 필드에 대한 데이터가 캐시에 존재하지 않는다면 에러를 throw 한다 |
cache-and-network | 캐시와 서버로 동시에 요청을 실행한다. 서버에서 응답을 받아 자동으로 캐시를 업데이트한다. 빠른 응답을 원하고 서버 데이터와 캐싱된 데이터를 일관되게 유지하고 싶을 때 사용한다. |
network-only | 캐시로 요청이 가지고 않고 오직 서버로만 요청을 실행한다. 요청에 의한 응답 결과는 캐시에 저장된다. 서버 데이터와 일관성을 유지하고 싶을 때 사용할 수 있지만, 캐시된 데이터가 있을 때도 빠른 응답을 제공할 수 없게 된다. |
no-cache | network-only와 비슷하지만, 요청에 의한 결과값이 캐싱되지 않는다. |
standby | cache-first와 비슷하지만, 이 요청에 대한 응답 결과는 캐시에 자동으로 업데이트 되지 않는다. refetch와 updateQueries를 사용하여 수동으로 업데이트할 수 있는 상태가 된다. |
이렇게 많은 옵션들이 있다. 상황에 따라 원하는 정책을 골라서 사용하면 될 듯 하다.
