https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
앱과 웹뷰 모두 graphql 을 사용하는 상태에서 데이터 정합성을 유지하기 위해 웹뷰에서...
# 질문
u
앱과 웹뷰 모두 graphql 을 사용하는 상태에서 데이터 정합성을 유지하기 위해 웹뷰에서 앱의 아폴로 캐시를 업데이트 하는 인터페이스를 호출하는게 오버 엔지니어링일까요?
h
아뇨 근데 Persist & Offline sync 하는거 아니면 실제로 개선할 수 없을거같고
진실의 원천을 원래 캐시로 쓰고 있는게 아니라면 아키텍처 전환이기 때문에
프로젝트가 이미 많이 발전해있고 이해관계자가 많을 수록 어려울 수 있습니다.
저는 오버라고는 생각안해요 이전에 똑같이 잘해서 잘뽑아봤기때문에
u
좋은 답변 감사합니다. 웹뷰에서 앱으로 나왔을 때 정합성 유지가 힘들어서 고민중에 있는데 캐시를 말씀드려 봐야겠네요.
근데 Persist & offline sync 는 어떤걸까요?
h
initial state 넣어줘야죠
오프라인은 아닌거같고
맞나
모르겠다 암튼
웹뷰가 항상 떠있는게 아닐거기 때문에
메시지를 주고 받아 동기화하는건 웹뷰가 떠서 웹뷰에서 돌릴때나 의미 있을테고요
반대는 어디 Pref store 에 상태를 계속 persist 해놨다가
웹뷰켜질때 초기 상태로 넣어주거나 해야죠
u
앱 -> 웹뷰의 경우이군요. 그 부분도 리서치 해보겠습니다. 감사합니다. 복잡하게 짜게 되도 데이터 정합성은 중요하겠죠?
h
아뇨 딱히 정합성 맞추려고 하는 작업은 아닌거같은데요
일관성 말씀하시는거일듯 한데
애초에 API가 진실의 원천이고 GraphQL 올바른 패턴으로 쓴다면 앱웹 넘나든다고 일관성 깨질게 많이 없긴 하고요
깨진다면 하나의 Type에 대한 Context가 앱 웹 전반적으로 넓게 퍼져있는 상태로 뮤테이션 때릴 때인데
인프라 제약사항 있는거 아니라면 아무래도 Subscription 이나 Live Query 도입하는게 훨씬 쉬운 솔루션이죠
u
넵 일관성이 올바른 용어인 것 같네요. 동일한 API 를 쓰고 액티비티가 활성화 될 때마다 쿼리를 호출한다면 일관성 문제가 없을텐데 지금 그러지 않고 있습니다. 이게 서버에 부하를 주는것 때문에 그런데 액티비티가 활성화 될때마다 쿼리를 호출하는게 맞을까요? 그럼?
h
넴
CDN 으로 해결하는게 더 쉽지 않을까요
지금 말씀하시는건 클라이언트 캐시 전략을 오프라인 우선으로 변경하겠다는 얘기인데
앱 아키텍처 변경보단 CDN 하나끼는게 더 쉽긴하죠
아님 라이브 쿼리를 쓰시거나
섭스크립션은 해결이 안되겠네요 액티비티자체가 백그라운드로 갈테니
u
CDN 으로 해결하는건 어떤 의미일까요? 제가 아는 CDN 개념은 리소스 로딩 빠르게 하는거 밖에 없어서...
h
Persistent Query 요청응답을 CDN에 캐시하는거요
이건 아폴로 쪽에 문서랑 블로그가 많이 제공되니 확인해보세요
u
오 읽어보겠습니다 감사합니다
Open in Slack
PreviousNext
Powered by