들어가며
Apollo 클라이언트는 GraphQL 애플리케이션에서 클라이언트 측 캐시를 관리하고 조작하는 데 강력한 도구를 제공합니다. 이러한 도구 중 writeFragment와 refetch는 이메일 검증과 같은 변동 사항 후 캐시를 업데이트하는 서로 다른 접근 방식을 제공합니다. 이 블로그에서는 두 가지 방법을 살펴보고, 사용 사례와 장단점을 분석해 보겠습니다.
writeFragment를 사용한 직접 캐시 조작
사용자의 이메일이 인증되면 Apollo 클라이언트 캐시의 verified 상태를 네트워크 요청 없이 업데이트해야 합니다. 이는 writeFragment 메소드를 사용하여 달성할 수 있습니다. 다음은 변동 사항을 처리할 수 있는 예시입니다:
const [verifyEmail] = useMutation<VerifyEmailMutation, VerifyEmailMutationVariables>(
VERIFY_EMAIL_MUTATION, {
onCompleted: (data: VerifyEmailMutation) => {
const { verifyEmail: { ok } } = data;
if (ok && userData?.me.id) {
client.writeFragment({
id: `User:${userData.me.id}`,
fragment: gql`
fragment VerifiedUser on User {
verified
}
`,
data: { verified: true },
});
navigate("/");
}
},
}
);이 예시에서는 verifyEmail 뮤테이션이 성공적으로 완료된 후 사용자의 verified 상태를 캐시에서 true로 직접 업데이트합니다. 이 방법은 추가 네트워크 요청을 피하면서 효율적이지만, 애플리케이션 전반에 걸쳐 데이터 일관성을 유지하기 위해 캐시를 세심하게 관리해야 합니다.
refetch를 통한 캐시 업데이트
대안으로, refetch 메소드는 서버에서 데이터를 다시 가져와 캐시를 업데이트하는 방식을 사용할 수 있습니다. 이 접근 방식은 캐시가 서버와 일치하도록 보장하지만 추가 네트워크 요청의 비용을 지불해야 합니다. 이메일을 검증한 후 refetch를 사용하는 방법은 다음과 같습니다:
const { data: userData, refetch } = useMe();
const onCompleted = async (data: VerifyEmailMutation) => {
const { verifyEmail: { ok } } = data;
if (ok && userData?.me.id) {
await refetch();
}
};refetch를 사용하면, 성공적인 뮤테이션 후 useMe 쿼리를 다시 요청하여 서버에서 최신 데이터를 가져와 캐시를 업데이트합니다. 이 방법은 구현이 간단하며 데이터가 오래되거나 일관성이 없는 위험을 줄일 수 있지만 서버와 네트워크에 더 많은 부하를 줍니다.
비교 및 모범 사례
-
성능:
writeFragment는 추가 네트워크 요청을 피함으로써 더 높은 성능을 제공합니다. 네트워크 효율성이 우선시되거나 업데이트된 데이터가 애플리케이션의 다른 데이터에 의존하지 않는 경우에 이상적입니다. -
데이터 일관성: 데이터 일관성을 보장하는 것이 중요한 복잡한 애플리케이션에서는
refetch가 선호됩니다. 여러 컴포넌트가 동일한 데이터에 의존하는 경우에 유용합니다. -
단순성:
refetch는 서버가 최신 데이터를 제공한다는 점에 의존하여 구현이 더 간단합니다. 수동 캐시 업데이트 대신 GraphQL 쿼리가 모든 종속성을 처리합니다.
마치며
writeFragment와 refetch 선택은 애플리케이션의 특정 요구 사항에 따라 달라집니다. 성능, 단순성 또는 데이터 일관성을 우선시하는지에 따라 적절한 방법을 선택하는 것이 중요합니다. 간단한 애플리케이션에는 writeFragment가 효과적인 도구일 수 있으며, 높은 신뢰성과 일관성이 필요한 애플리케이션에서는 refetch가 서버의 최신 데이터를 제공하는 안전한 메커니즘을 제공합니다.
