GraphQL과 Apollo 활용기 +a !

jayson·2019년 8월 22일
0
post-thumbnail

최근 GraphQL을 이용한 프로젝트를 진행한 적이 있다.
GraphQL에 관한 포스팅은 내 이전 velog를 확인하자.
https://velog.io/@jayson/project-개.고.수-반려동물을-위한-커뮤니티

RESTful API와 다른 고유의 특징을 가지고 있는 GraphQL은
Quary와 Mutation을 통해 요청을 보내 줄 수 있다.

대게 Quary는 DB에 변형을 주지 않는 요청을 보낼때 사용되고
Mutation은 DB에 변형을 일으키는 요청을 보낼 때 사용하지만,
절대적인 것은 아니다.

특히 Client에서 Mutation 요청을 보내 DB의 값이 변하고, 변한 값을 바로바로 Component에 적용시켜주기 위해서는 Mutation 내부에 옵션으로 refetchQuaries 를 추가해 주어 Mutation이 종료된 후에 다시금 해당 Component에서 Quary를 보내 변경된 DB를 읽어 오도록 할 수 있다.

"이런 개념이구나" 하고 프로젝트에서 로그인 화면을 진행하던 도중

어찌보면 당연하지만, 병렬로 배치된 컴포넌트의 Mutation에서 refetchQuaries를 실행하더라도 이웃한 컴포넌트의 Quary를 재 실행 시킬 수는 없다는 것을 확인했다.

위 : 병렬로 설계된 Main.tsx / 아래 : Headbar 컴포넌트를 바꿔주고 싶은 login.tsx

위의 Headbar 컴포넌트의 Quary는 GET_ME 라는 quary를 보내 자신이 로그인 상태인지 확인하여 로그인 상태일 경우 Menu의 구성이 바뀌는 코드이다.

login.tsx에서 refetch를 해 주지 않더라도, Mutation은 서버에 보내졌고, page를 refresh 할 경우, Headbar component는 제대로 변경이 되긴 하였다.

하.지.만.

로그인 버튼을 누르면 페이지가 변환되면서 refresh를 하지 않더라도 component의 상태를 변화 시키고 싶었지만 변경이 되지 않았다! (왜! 새로고침하면 잘 되는데! 왜!)
Mutation을 보내고 일부러 setTimeout도 걸어보고 refetchQuaries도 사용해 보았지만, 그럼에도 불구하고 Mutation이 실행 된 후 Headbar 컴포넌트의 상태는 변하지 않았다.

원인을 알아보던 중,
나는 그 이유가 Apollo가 기본적으로 지원하는 Cache 때문이란 것을 알았다.

프로젝트 당시에는 프로젝트의 빠른 진행을 위해 당장의 문제를 해결하기 위해 client.cache.reset(); 이라는 Cache를 삭제해 버리는 기능을 이용하였지만 프로젝트를 마친 후 Apollo가 가지고 있는 Cache의 기능적 특징이 무엇이 있는지 궁금해 졌다.

이에 가장 정확하고 확실한 공부법인 Document 정독하기를 실시하였고,
https://www.apollographql.com/docs/apollo-server/features/caching/
생각보다 어렵지 않게 Apollo가 지원하는 Cache의 기능들을 확인 할 수 있었다.

그 중에서는 Apollo가 단순히 Client에서만 코딩을 실시하는게 아니라
Server에서도 해당 Quary의 지속시간을 설정해 줄 수 있었다.

이와 같은 방법을 통해, 로그인 요청이 있기 전에는 지속시간이 있는 Cache를, 요청을 받은 후에는 지속시간이 없는 refetchQuaries를 실행해 문제를 해결할 수 있지 않았을까 생각해본다.

이번 bloging을 통해 깨달은 가장 큰 교훈이 있다면
"급할수록 Docs참고" 가 아닐까 싶다.

profile
코딩과 생활 가장자리

0개의 댓글