This message was deleted.
# 질문
s
This message was deleted.
👀 1
h
post.viewCount(timestamp: Int!)
쿼리는 멱등해야하는 걸까요?
넹 (물론 맥락에 의존적입니다만)
왜냐면 캐시가 내장된 클라이언트는 그 가정에 의존해서 cache lifecycle을 구현하기 때문입니다
u
맥락에 의존적이라고 하셔버리다니 ㅎㅎ
h
이건 서버사이드에서 Redis 같은거로 캐시를 구현해도 마찬가지이기 때문에 비슷하게 생각하시면 좀 쉬울거같습니다.
항상 스키마에 드러내지 않는 가정들이 있기 마련이잖아요? ㅎㅎ 대표적으로 auth 라던가 하는
저는 한 세션 상태에 대해서 멱등한게 베스트라고 생각해요
+ 참조한 노드타입의 엔티티들 수명은 별개
u
캐시 라이프 사이클 != 세션 을 의미하신거죠?
h
Post viewCount 따위를 실제로 구현한다고 치면 얘기였습니다
거기서 캐시를 두고 retrieve 한다고 가정하면
timestamp 같은걸 수명에 엮는게 아주 일반적일거 같거든요
세션은 의존하는 대표 맥락의 예시구용
클라이언트 캐시에 각각 수명을 부여하면 세션 단위로 생각할 수 있을테니
세션에서 따로 전이가 없었다면
캐시된 데이터를 사용해도 안전하다고 가정할거 같습니다.
그럼 post.viewCount 가 매번 증가하는지 아닌지는 사실 큰 의미가 없는게
어차피 새로 요청을 안함
이걸 새로 요청하게 하려면 명시적인 전이(mutation) 를 하거나
수시로 변하는 추가 환경 맥락(timestamp 따위)를 의존하게 하거나
저는 이걸 명시적으로 드러내는걸 선호하기 때문에 맴 위의 예시처럼 추가 의존성을 스키마에 같이 적는걸 선호합니다.
그러지 않으면 저걸 폴링해도 클라이언트 구현에 따라서는 요청을 생략해버려도 전혀 이상하지 않은 문제가 생김
실제로 apollo 같은거 쓰면 cachePolicy 에 따라서 요청이 생략될겁니다.
음 얘기가 어렵네
결국 저 문제가 viewCount의 수명을 소속된 객체(Post)에서 독립적으로 가져가고 싶은게 문제잖아요?
그럼 부모보다 더 narrow 된 수명주기를 field 에 직접 넘기는게 자연스러운거죠
암묵적으로 때울수도 있지만 저는 별로라고 생각하고요
아 뭔 말을 이리 쓸데없이 어렵게 하지... 피곤한가봐용 ㅠ
u
ㅎㅎ 무슨 말씀인지 알 것 같아요
캐시를 고려하면 그게 클라이언트드 백이든 사실 멱등할 수 밖에 없을껄? 이렇게 들렸습니다 ㅎㅎ
👍 1
아니면 timestamp 로 명시적으로 드러내던가
h
암튼 딱 스키마만 봤을 때 • Post.viewCount: Post 수명 따라가겠거니 함. Post 가 전이될 때 만료되는게 자연스러운 것으로 이해함 • Post.viewCount(timestamp): timestamp 를 요구하는구나. Post랑 별개로 만료시키는걸 의도한걸로 이해함
🙌 1
이런 힌트가 될 수 있을거같아요
u
감사합니다. 저도 좀 더 정리가 되는 것 같아요
크 역시 여기 질문을 남기길 잘했네요
u
여기 물어보셨었군요 ㅋㅋ