GraphQL is a query language for APIs and a runtime for performing queries on data that already exists.

GraphQL Korea

저는 B하고 있는데 C로 넘어가시는 이유가 있으세요??

뮤테이션은 뷰일관성을 보장하도록 정보를 리턴하셔야 합니다.

단순히 응답결과의 인코딩된 코드를 반환하고 뷰에서 해석하는게 아니라요

mutation이 하나의 리소스만 수정하지 않는 경우가 보이더군요. addPepople이지만 team 관련 리소스도 업데이트 된다던가

그래서 막 혼합하는것 보다는 C로 통일하는게 좋지 않을까 생각했거든요.

<https://developer.github.com/v4/mutation/addprojectcolumn/>

github같은경우 *clientMutationId* 를 기본적으로 반환 하던데 이거보니 result가 의미있을까 생각도 들고

이런 저런 생각이 썪이고 있네요 ㅎㅎ

query가 뷰의 일관성을 보장하는건 이해가는데 mutation도 유지되어야하나요?

```mutation AddPeople(input: ...) {
  # 응답 코드같은게 필요하면 스칼라 타입으로 넣습니다.
  result

  person # 생성된 User... 당연히 필요할거구요

  # 중요한 건 실제 뷰를 mutate 해야 한다는 점입니다.
  # 가령 말씀하신대로 팀 관련 정보가 업데이트 된다고 치면 업데이트 될 팀을 넘겨줘야 합니다.
  team
}```
뮤테이션이 왜 “뮤테이션“으로 이름지어 졌는가는 클라이언트 관점에서 생각하셔야 합니다.

해당 뮤테이션이 mutate 하는 건 클라이언트 (화면) 에서 의존하는 어떠어떠한 부분이다 라는걸 선언해주시면 graphql client 가 해당 부분을 찾아 레코드를 업데이트 하는거에요. ID 스칼라도 해당 부분을 식별하기 위해 있는거구요

사용자 코드로 updater 를 짜넣는건 리스트 뮤테이션 같은 몇 예외 상황을 위해 있는 겁니다.

뷰 프래그먼트 쓰시면 해당 프래그먼트는 쿼리에만 들어가는게 아니라 뮤테이션에도 그대로 들어갑니다

아 말하신 뷰의 일관성은 제 질문 같은 경우 addPeople: People에서 보장하라는 이야기시죠?

예를들면 제가 제품에서 쓰는 뮤테이션 중 하나는 이런식으로 생겼습니다.

```mutation CreateDayOffForm(input: {
  ...
}) {
  dayOffForm: createDayOffForm(input: {
    ...
  }) {
    id
    # 폼 의존성 업데이트
    ...DayOffForm_subject
    user {
      id
      dayOffCount(year: $year) {
        ...DayOffCountCardContainer_dayOffCount
      }
      workReport(input: {
        ...
      }) {
        # 근무 리포트 - 근무시간차트 의존성 업데이트
        ...MonthlyWorkReport_WorkTimeChart
      }
      workData(input: {
        ...
      }) {
        # 월간 캘린더 - 휴가 등록 가능한 날짜 별 행 업데이트
        ...WorkCalendarCard_dailyAggregationSource
        dailyAggregation @client {
          ...WorkCalendarCard_HalfDayOffDayRow
          ...WorkCalendarCard_FullDayOffDayRow
        }
  
        # 주간 캘린더 - 스케줄 업데이트
        ...WorkCalendarCard_schedulesSource
        schedules @client {
          ...WorkCalendarCard_WeeklyCalendar_dayOffSchedule
        }
      }
    }
  }
}```

같이 people이라고 써소 답변이 Person 이라고 해야하려나

핵심은 유저코드로 받을 값을 명시하는 것이 아니라(물론 가능합니다. 필요하면 쓰시면 됨..)

graphql engine 에게 값이 변경되었음을 알려야할 레코드를 명시하는 것이 중요하다 (뷰 일관성 보장, 일관성 필요 없으면 안쓰셔도 됨)

네 그부분까지는 고민 못했는데 이번에 알게되었네요 감사합니다

저 clientMutationId 는 custom updater 다루기 편하라고 일관적으로 넣어주는 것 같아요

주로 리스트 업데이트나 레코드 삭제 같은 것들이 해당될 듯 하네요

현 회사에서는 GraphQL을 안쓰고 있는데 이전 회사에서는 캐시레이어가 Dataloader로 대체(...)되어서 운영했었어요.

"dataloader 중심" 이라는게 어떤 의미인지...

로더를 최대한 많이 생성하여 운영한다? 정도의 의미로 적었습니다

뭐 로더 있는 건 다 쓰죠.. 아주 초기엔 안쓰고 빨리 리졸버 짜기도 하는데, 기본적으로는 다 만들고 더 최적화 더 필요하면 커스텀 배치 로더를 만들기도 합니다.

적어도 루트쿼리엔 로더 안쓰는 리졸버가 없죠

서버든 클라이언트이던 graphql 에서 서비스 엔드포인트에 맞닿아 있는 부분엔 무조건 캐시레이어가 들어가는데 data-loader가 서버 측의 대표적인 캐시레이어 입니다.

사실상 GraphQL Server의 전신같은 녀석이라 안쓰이는 데가 더 드물어요 ㅋㅋ

혹시 DataLoader + Redis/Memcached 붙여서 쓰시는 분 계신가요??

저도 장점 알고나니 점점 Dataloader 만으로만 만드니 ㅎㅎ 괜히 불안한 마음에 질문던져봤습니다. 다들 잘 쓰고 있군요. 장점에 비교하여 소개가 적더라구요.

실제 사례 있을까요? 캐시 클러스터링 하는 용도인거죠?

모르겠어요 ㅠㅠ <https://www.youtube.com/watch?v=MPRQRlrixls>

요거 기반으로 쿼리 기반 캐싱 구현했는데요.

query variable이 엄청 다양하면 무의미해질거같아서… 어차피 DataLoader 떡칠되어있으니까 batch함수 내부에서 캐싱 로직을 일반화해볼까 하고 있었어요.

캐시 수명이 per-request 를 넘어가는 순간 다른 종류의 엔지니어링 문제가 되니 ㅋㅋㅋ 전 스케일 그 정도 서비스를 다룰 일이 없어서 쓸일이 없을것 같네요

```class CachedDataLoader extends DataLoader {
  …
}```


리퀘스트 들어올때 데이터로더 생성하여 사용하시죠?

&gt; batch함수 내부에서 캐싱 로직을 일반화해볼까 하고 있었어요.
사실 이 것만 해도 캐시 정책(키) 잘못 만들어서 버그가 넘 자주 나는 것….

nestjs에서 요청당 생성 깔끔하게 만들어보려고 고민해서 지금은

근데 만약 일관성 조금 포기해서 캐시끼고 최적화한다 치면

Redis 같은걸 운영하기 보단 CDN으로 뿌릴 것 같네요

좀 커스텀하게 만들어서 운영하고 있어요

<@UURM5ES8N> 혹시 캐시레이어가 DataLoader로 대체되었다는건 DataLoader를 request 당 생성이 아니라, 전역으로 생성해놓고 In-memory 캐시처럼 사용했다는 말씀이세요??

아 아뇨; 별도의 redis/memcache같은 롱타임(?) 캐시레이어를 사용하지 않고 않고 request마다 dataloader하는것만 이용했었다는 의미였어요.

~혹시 “전회사“가 여기 말씀하시는건가…~

지금 데이터로더 요청별로 LRU 캐싱만 적용한 상태인데

cdn 캐싱, 통쿼리 캐싱, 리졸버 수준 캐싱 이런거 추가로 사용하시나요?

비용이 비싼 작업에는 리솔버 수준 캐싱이 필요할 것 같긴 한데요.

저도 리졸버 수준 캐싱까지 만들어 놨는데, 만들어만 두고 사용할만한곳을 찾지 못했네요 ㅎㅎ

근데 사실 그정도 수준이면 저라면 그냥 서비스를 분리해서 해당 서비스에서 알아서 캐시하게 할 것 같아요 (..)

리졸버 수준 캐시라는게 리졸버 함수 자체를 memoize 한다는 그런건가요?

저도 바환님 말씀처럼 할거같은데

이 쪽 context 객체는 immutable 하다는 보장이 딱히 없어서

variables랑 context serialization해서 캐시키로 쓰면 되지않을까요(?)

뭐 그럼 되겠죵. 근데 단일 리졸버가 그렇게 비싸질 일이 있을까 싶네요.

사실 쿼리 리졸버는 거의 최적화할 일이 없고

로직 별로 많이 다를꺼같은데 dataloader뒤 늦게 사용하고 batchFunction만 최적화 하면 지금까지는 성능저하가 있을만한게 별로 없네요

로더별로 캐시맵을 따로 설정가능하니, 무거운 작업 있다면 로더를 전역 캐시맵을 붙이는것도 괜찮을꺼 같은데 이렇게 쓰시는 분은 없죠?

저는

admin.user.id + user.id + query 해시 + variables 해시 + 캐시 버전

요렇게 해서 키로 만들었어요.

{API|GQL}:{PUBLIC:user.id|orgId}:{cacheKey|reqHash}

api controller또는 gql에서 public정보랑, org캐싱인지정보 받고 위처럼 키 생성하게끔 만들어 뒀네요

전 개인적으로는 verbose 하게 다 만드는게 취향 ㅋㅋ

아마 갠프로젝트 한다면 코드생성기 쓸 것 같네요

ㅋㅋㅋ 전 js 가 제일 빈약하다고 생각하고 있었는데

혹시 그럼 가장 잘 준비된 녀석은 어떤 녀석일까요?

아님 페북 내부에서만 쓰는 프레임워크 X 라던가...

&gt; JS로 API-Gateway Proxy(?) 하는게 제일 괜찮아 보이는데 어떤 단점들이 있을까요?
글쎄요... 단절이나 일관성 이슈겠죠? 근데 GraphQL 엔드포인트가 여러 백엔드 통합하는건 워낙 베스트 프랙티스라

&gt; 혹시 JS 런타임 말고 타 언어나 환경에서 GraphQL 서비스 하시는 분 계신가요?
2월에 파이썬 graphql 서버 발표해주실 분 계셨는데 코로나 이슈로 취소됐었어요 ㅠㅠ

저도 궁금한게 다른 환경에서 DataLoader가 잘 작동하나요??

&gt; 저도 궁금한게 다른 환경에서 DataLoader가 잘 작동하나요??
오히려 다른 언어들은 공식 구현체가 없으니 프레임워크 레벨에서 데이터로더를 내장해서 제공하더라고요.

dataloader 자체는 하는일이 굉장히 단순한 녀석이라 안될 이유도 딱히 없고, 프레임워크 레벨에서 잘 통합된 추상화 계층을 제공하니 더 편하게 쓰지 않을까요

파이썬에서는 graphene 라이브러리를 많이 씁니다!

아폴로 클라이언트는 베타인 3.0 부터 gc 를 지원하고 릴레이는 예전부터 있어요

<https://www.apollographql.com/docs/react/v3.0-beta/migrating/apollo-client-3-migration/#whats-new-in-30>

<https://relay.dev/docs/en/runtime-architecture.html#docsNav>

레퍼런스 카운팅이라고 알고 있습니다

<https://github.com/FormidableLabs/urql-exchange-graphcache/releases/tag/v2.0.0>

URQL graph cache exchange 에서도 v2 에서 구현했네요

오 이런 기능들이 내재되어 있었군요 제대로 안읽어서 몰랏네요

클라이언트 환경이랑 GraphQL 클라이언트는 어떤거 쓰세요?

리액트 + 타입스크립트 + 아폴로 입니다

Apollo면 Mutation 응답으로 변경된 객체를 내려주면 자동으로 전파돼요!

변경된 객체를 내려주고 있습니당

그런데 변경된 객체를 어디로 내려주는건가요?

Apollo가 알아서 내부 Cache(Redux)를 통해서 해당 id를 가지고 있는 객체의 object를 전부 바꿔요 ㅎㅎ

저는 화면에서 렌더링이 반영이 안되고 있는 상황입니다. :sob:

```type Item {
  id: ID!
  checked: Boolean!
}```
이런 모델에서

음? 그러면 Apollo DevTool 크롬에 설치하셔서 Cache 한번 확인해보세요 ㅎㅎ

아니면 cache를 console.log 찍어보셔도 되구요

Mutation 쿼리 한번 보여주실래요??

```mutation toggleTagStatus($input: ToggleTagStatusArgs!, $language: LanguageType) {
  toggleTagStatus(input: $input) {
    code
    createdAt
    updatedAt
    type
    isRecommend
    priority
    translations(language: $language) {
      code
      createdAt
      updatedAt
      language
      tagCode
      name
    }
  }
}```


```query tags($input: TagPageArgs!, $language: LanguageType) {
  tags(input: $input) {
    totalCount
    edges {
      code
      createdAt
      updatedAt
      type
      isRecommend
      priority
      translations(language: $language) {
        code
        createdAt
        updatedAt
        language
        tagCode
        name
      }
    }
  }
}```
```이렇습니다```


일단은 id 필드가 컨벤션인걸로 알고있어서, code 필드의 값이 키로 캐시에 잘 들어가는지? 확인해보셔야될꺼같구

바뀐값으로 Mutation 응답이 잘 오는지도 확인해보셔야될꺼같아요

아폴로에서 자동 전파 할때 기본적으로 id 값을 감지한다는 말씀이신거죠?

흠… apollo-link-state 사용할때 그랬던거같은데, 확인해보시면 될꺼같아요!

devtool 설치하시면 cache 탭있어서

어떤 값들이 캐시에 들어가있는지 볼 수 있어요!

만약에 제대로 안들어가고있다고 판단되시면

<https://www.apollographql.com/docs/react/caching/cache-configuration/#custom-identifiers>

요렇게 Custom Identifier 설정하실 수 있어요

&gt; By default, the `InMemoryCache` attempts to generate a unique identifier for an object by combining the object’s `__typename` field with its `id` or `_id` field.

맞네요 기본적으로 id 필드로 한대요

캐시리디렉트 사용 주의하세요 v3에 api 싹다 바뀝니다

넵 ㅋㅋ 저는 refetch 하는거같아요

ㅋㅋ 지혁님 감사합니다! 엄청빠른 응답속도에 감동했습니다

앞으로도 질문 많이 부탁드려요~~ ㅋㅋ

refetch 하는게 빠르긴 한데 몇가지 문제가 있죠.

• 쿼리가 의존하는 variables "맥락" 을 공유해야함
• 불필요한 fetch
• 캐시 구조 변경은 피할 수 없음
가령 page: 1, page: 2 요청에 대한 캐시가 이미 있고 아이템이 추가되서 page: 1 의 쿼리를 refetch 한다고 하면 1페이지의 마지막 요소가 뷰에서 사라지게 됩니다.

제일 쉬운 방법은 페이지네이션 컨테이너 캐시 정책을 cache-and-network 로 매번 동기화 하는거일테지만

사실 페이지네이션 코드가 일관적이라면 커스텀 updater 를 만들어 사용해도 쉽게 코드 공유가 가능합니다. (릴레이의 PaginationContainer 처럼) 그리고 이렇게 하려면 캐시 키가 페이지 넘버 대신 아이템을 참조하는 커서기반 페이지네이션으로 바꿔야되고요.

자주 동기화가 필요한 앱이라면 어쨋든 refetch 해야 할 수 있지만... 저는 가능하면 refetch는 줄이기 위해 설계부분 부터 고민은 해볼 가치가 있는 것 같습니다.

이런 부분은 백엔드에서 일방적으로 스키마가 정해져선 절대로 달성할 수 없기때문에

저는 백엔드에서 제공된 스키마를 확장해서 커스텀 스키마를 사용하게 되는 경우도 많은 것 같아요

스키마 자동으로 뽑힌다고 쳐도 구현 바인딩 하기 어려우실 텐데 직접 맞춰 생성하시거나 클라이언트 구현체를 쓰시는게 나을거같아요

Prisma client 나 Postgraphile 같은 녀석들

Prisma 사용해서 아~주 편하게 서버 구현을 했었는데,
맛들렸는지 mongodb에도 db 스키마 읽어서 단순 all,info,create,update,delete관련 resolver를 싹다 만들어주는거 없는지 찾아보고있습니다 : )

prisma 의 어떤 부분을 대신하고 싶으신건지에 따라 다른거같아요

<https://graphql-korea.slack.com/archives/CMLT64A7M/p1584061415013500>

방금 나온 따끈따끈한 건데 이게 찾으시는 거에 가까울 수도..

prisma 1를 현재 잘 사용하고 있지만
prisma 사용이 제약될 때 대체 용으로 사용 가능한 것을 찾고 있습니다.

Hasura쪽도 확인해봤고, 또 다른게 없을까하고 계속 검색중입니다.

저도 열심히 찾다가. 만족 못하고  json -&gt; orm where 만들어주는 유틸 만들어서 사용하고 있습니다.

입맛에 안맞으면 직접만드는것이 또 재미있죠...
프로젝트 휴식기 오면 서브로 만들어야겠네요

잘 만들어서 하나 공개하시는것도 ㅎㅎ..

평균적으로 5% 가량 증가하네요… 뭐지 이게;

<https://github.com/apollographql/apollo-server/blob/afbb15038d02f753f7b4a98a40f5028a1f97b2d6/packages/apollo-server-core/src/requestPipeline.ts#L134-L182>

아직 브랜치를 다 쫓아가보진 않았지만, 증상만 보면 cache hit 를 해도 원래 수행하던 오퍼레이션을 똑같이 처리해버려서 해싱하는 비용만 추가된 것 같은데…………. -_-;;;;;;;

아니 요청 사이즈 준건 좋은데.. ㅋㅋ 도큐먼트 파싱을 스킵해야 의미가 있는거 아닌가요 ㅋㅋㅋ 뭐지 진짜

저는 보통 컴포넌트 당 프래그먼트 1~2개, 많아야 3개 나오는거 같은데

<https://gist.github.com/yunseop-kim/cbf5e01eac4a82bbd3688442936e094f>

실제 작성한 코드인데요, fragment를 안 쓰고 있었습니다. 일단 학습을 좀 해야겠네요.

저는 비지니스 로직과 Present 부분을 분리시키곤 합니다.

위 gist 쪽을 예제로 들면 `dataSource` 쪽이랑 return 의 JSX 부분이 분리될 수 있어보여요

음, 변수 dataSource 를 말씀하시는거 맞죠?

지금 현재는 아폴로 캐시 부분은 레이어를 나눠서 따로 빼 놓은 상태가 되긴 했습니다. ㅎㅎ

넵. ㅎㅎ :clap:
그리고 코드가 너무 긴게 문제가 된다면 variables 만드는 부분이나 update 부분의 콜백을 별도의 파일로 분리하는 것도.. 선택지중 하나일것 같아요. (해당 부분이 "전체 로직" 를 이해하는데 크게 문제가 되지 않는다면)

네, 저 gist 이후로 말씀하신것처럼 처리를 어느정도 해놓긴 했는데… 그래도 뭔가 긴 거 같은 기분은 가시질 않네요 ㅋㅋ
회사가 다국어 지원을 해서 다른 서비스보다 처리할 게 더 많아서 그런건가 싶기도 하구요.

질문 감사드려요 ㅎㅎ cache 업데이트가 아얘 안되는건가요??

cache update는 되는데 무한적으로 반복됩니다... :disappointed:

혹시 JS 환경이라면, Promise.all로 해도 마찬가지일까요??

넵 Promise.all로 묶어도 똑같더라구용...

흠… 개인적인 생각으로는 하나의 쿼리로 묶는게 맞지않나 하는 생각이긴해요

mutation 내 update 메소드에 console을 찍어보면 계속 반복적으로 찍히면서 렌더가 너무 많이 된다고 react에서 오류를 뿜내용

그치만 뮤테이션이 그렇게 나오지 않아서 그런거겠죠 ㅋㅋ

넵넵 그래서 지금 서버분이랑 list를 args로 넘기는게 맞나에 대한 고찰을 하는 중이었습니당.

글쎄요 저라면 저런 경우면 Mutation 필드를 하나 더 뺄거같긴해요. for를 돌면서 쿼리하는게 엄청 이상하긴 하니까요. 앞에 batch 네임스페이스 붙여서 하나 더 만들꺼같아요 ㅋㅋ

배치를 지원하지 않는 뮤테이션을 배치로 쓸 때인거죠? 보통은 클라이언트에서 커스텀 배치 뮤테이션을 만들어 사용합니다

오 혜성님이 말씀하신 방법이 짱이네요

오.. 커스텀 배치 뮤테이션으로 검색해보겠습니다...

resolvers 필드에 resolver 만드셔서 넣으면 돼요

오... 우선 해보고 모르겠으면 다시 질문 드리겠습니다 ! :+1:

<@UN4AJARCN> 근데 그러면 custom resolver 안에서 axios 같은 http client로 콜을 하나요?

아뇨 그냥 그대로 apollo client 써요

뭔가 for로 여러면 http 콜하는게 graphql 스럽진 않은거같아서요

그렇다고 쿼리 스트링을 interpolation하는것도 뭔가 이상하고..

그 사실 apollo-link-dedup 이나 apollo-link-data-loader 같은 녀석들이 똑같은 짓을 해요

debounce stack 에 묶어놨다가 한 쿼리로 묶어서 주고받는 식으로

서버쪽에서 로깅하기 힘들거같은데;;

비슷하게 ad-hoc 하게 구현할 수 있습니다

apollo-server 쓰시면 별 문제 없어요

mutation 때문이라기보단 캐시 의존하고 있는 쿼리 다른게 문제일 거에요

mutation 하나 fullfiled 될 때마다 컴포넌트가 리렌더 되면서

그걸 다시 args 로 넘기고 있거나 하실듯

<https://github.com/prisma-labs/http-link-dataloader>

해당 라이브러리 사용해서 해결해보도록 할게용 ~

mutation call 들을 Promise.all 로 묶어 한 번에 처리하는 배치 같은걸 만드실 수 있을텐데 이게 어차피 서버에서 지원 안하면 트랜잭셔널한 처리는 못해요

아 이건 구현 참고하라고 올려드린거고

컴포넌트를 캐시에서 인디렉션 하시는게 맞는거같은데

그렇게 하면 mutation 후 서버에서 온 데이터를 다시 유저에게 보여주지 않아서 잘못된 데이터가 와도 유저에게 못 보여주지 않나용 ?

해당 mutation 이 캐시에 직접 의존하지 않고 사용자 액션(clickSave)에만 의존하도록 잘 인디렉션 해보시는게 해답일 듯 해요

mutation body는 캐시를 통해 전파되니까 꼭 직접 받지 않으셔도 되고요

이 변경을 mutation 이 스스로 재 참조 해서 문제가 발생하는거니까 (실제로 요청도 무한히 한다는 소리)

이 부분만 잘 제어해보세요. 멀리보면 서버에 배치 오퍼레이션 추가를 요청하는것도 좋습니다.

아님 apollo 같은 경우 쿼리 차단하고 explicit 하게 보낼 수 있어요

정 어려우면 이걸로 때울 수도 있으실듯

제가 지금 A라는 컴포넌트를 한 화면에서 여러개 보여주고 해당 컴포넌트들의 변화를 onSave때 모두 한번에 mutation해야해서, cache에 저장 후, onSave때 cache에 저장돼있는 값을 불러와서 mutation하는데 이 과정이 잘못된 건가요 ?

현재 mutation은 유저의 onSave action에 dep가 걸려있긴 합니당 !

&gt; 제가 지금 A라는 컴포넌트를 한 화면에서 여러개 보여주고 해당 컴포넌트들의 변화를 onSave때 모두 한번에 mutation해야해서, cache에 저장 후, onSave때 cache에 저장돼있는 값을 불러와서 mutation하는데 이 과정이 잘못된 건가요 ?
mutation 이 제각각 호출된다고 했을 때, 이게 별 순서 없이 제각각 업데이트 되는건 사용자 인지적으로 썩 좋은 경험은 아니라서 별도의 트랜지션을 정의하셔야 해요. 그리고 mutation을 기다리는 동안은 사용자 액션도 막아야 할 거구요.

저라면 마찬가지로 일단 변경 사항을 더 상위 컨텍스트에서 모아두겠지만, 뮤테이션은 그 컨텍스트를 제어하는 곳(부모 컴포넌트나 글로벌 스토어, 커스텀 뮤테이션도 해당됨)에서 다루고 트랜지션이 일어나는 동안은 별도의 로딩 UX를 제공하려 할 것 같네요.

<@UN4AJARCN> 정성스러운 답변 정말 감사합니당 ! Hyeseong님의 말씀이 UX 관점에서 좋네용 ! 감사합니당 ~

응답 받는 타입에서 ID scalar 사용하시나요? ID 스칼라를 사용하고, 생성된 아이템에 동일한 값을 반환하시면 apollo clinet cache 오동작 할 수 있습니다

GraphQL로 데이터 의존성을 관리하고 있다면 나머지 UI 상태가 글로벌에서 관리해야할 이유가 거의 없어집니다.

저는 UI 상태에 대한 맥락을 공유해야한다면 그 때마다 컨텍스트를 생성해서 사용합니다.

“상태 관리“와 “데이터 의존성“은 나눠서 생각할 수 이씅ㄹ 것 같습니다

사실 local state management가 이름을 그렇게 지어서 그렇지 실제로는 쓸일이 많지 않아요

컨커런트 리액트에서는 state와 resource라는 프리미티브를 분리하고 있고, 여기서 GraphQL이 관리하는건 state가 아니라 resource죠.

저도 Data Fetching해서 받아온 데이터는 Apollo에 넣고, 뭐 사이드바 접고 편다던지하는건 MobX 쓰고있어요 ㅋㅋ

예를 들어 어떤 데이터 30개를 fetch 해와서 30개를 리스트로 그렸습니다. 이 때 유저가 리스트에서 어떤 걸 선택할 때마다 선택된 object를 갖고 여러 컴포넌트들이 render 해야한다고 할 때, 유저가 id 3 인 걸 선택했다, id 9 인걸 선택했다, 이렇게 선택된 게 무엇인지 어떻게 관리하나요?
제 생각에는 다음과 같은 선택지들이 있을 거 같습니다.
1. mobx 나 컨텍스트에 선택된 id 만 저장해놓고, 반응해야하는 컴포넌트들은 이 id 를 가지고 apollo client cache 에서 가져와서 그린다.
2. 선택되면 apollo client cache 에서 선택된 object 를 가져와서 그 object 를 통째로 mobx 나 컨텍스트에 저장해놓는다. (이 경우 30개를 refetch 했을 때 object 가 바뀌어도 mobx 에 있는 object 는 그대로니까 랜더가 안될 거 같은데 맞나요?)
3. Apollo client local state management 에 doc 에 나와있는대로 관리한다.
혹은 다른 분들은 이런 상태관리를 어떻게 하시는지 궁금합니다.

&gt; 이 때 유저가 리스트에서 어떤 걸 선택할 때마다 선택된 object를 갖고 여러 컴포넌트들이 render 해야한다고 할 때, 유저가 id 3 인 걸 선택했다, id 9 인걸 선택했다, 이렇게 선택된 게 무엇인지 어떻게 관리하나요?
이거 케이스 조금만 더 구체적이면 답변 가능할 것 같아요

요구사항에 따라 다를거같긴한데 persistent 해야 한다면 리졸버를 하나 만들어 쓸 것 같고, 아니면 그냥 컨텍스트 하나 만들거같아요

그리고 graphql 클라들은 데이터들 전부 불변객체로 관리하고 있으니 굳이 id 만 dispatch 할게 아니라 통째로 컨텍스트에 넣는게 더 나을 것 같네요 여러모로

요는 예시에서 “지금 선택된 사용자” 라는게 어떤 의미를 가지는지 정의하는게 중요한 것 같습니다.

이게 도메인에서 중요한 의미를 갖는다면 데이터 그래프에, 단순히 UI 흐름 상 있는 휘발성 맥락이라면 리액트 컨텍스트에

뭐 특별히 redux, mobx 같은거로 서비스 레이어를 추가로 관리하고 ㅣㅇㅆ다면 써도 뭐 괜찮을거같긴한데요

개인적으로는 좀 복잡할거같다는 생각이…

완전 휘발성 맥락입니다. 예를 들어 맛집 object 가 있습니다. 필드는 id, 이름, 전화번호, 운영여부, 대표메뉴 가격을 갖습니다.
화면 왼쪽에 맛집 목록을 fetch 해와서 맛집 이름을 리스트로 보여주고 있습니다.
사용자가 이 리스트에서 맛집을 선택하면 화면 오른쪽에는 선택된 맛집에 대한 이름 전화번호 운영여부 가격대가 나옵니다.
화면 상단에 검색창에는 타이핑 할 때 맛집 목록을 auto suggestion 해주는데 선택되어 있는 맛집이 있을 경우 그건 제외합니다.
화면 구석 어딘가에는 선택된 맛집 대표 메뉴 가격에 뭔가 곱하고 더하고 해서 숫자를 보여줍니다.
새로고침 버튼을 누르면 맛집 목록을 전부 refetch 해오고 refetch 로 선택되었던 맛집의 필드 값이 바뀌었으면 각 컴포넌트들이 싱크되어 re-render 되어야합니다.
앱을 재실행하면 선택된 맛집정보는 날아가도 됩니다. (완전 휘발성입니다.)
이럴 때 선택된 맛집 정보를 어떻게 갖고 있어야 할 지 궁금합니다.
예를 들어 컨텍스트나 mobx 에다가 선택된 맛집 object 를 통째로 넣고 있으면 refetch 될 때 맛집 정보가 바꼇더라도 컨텍스트나 mobx 는 그걸 모르니까 re-render 를 위해 object 를 컨텍스트나 mobx 에 다시 갈아끼워 넣어야 할 것 같은데, 컨텍스트나 mobx 에서 선택된 맛집 id 만 들고있고 각 컴포넌트가 apollo-client-cache 에서 id 로 맛집 object 를 들고와서 랜더하고 있다면 refetch 시에도 알아서 re-render 가 될 것 같습니다.
이런 생각들을 하다가 이게 맞나? 다른 분들은 이런 UI 상태 정보를 어떻게 처리하지? 궁금해서 질문글을 올렸습니다.

하나하나 짚어보면 좋을 것 같습니다.

일단 맛집 object 라는게 휘발성 맥락이라고 하셨는데 제가 볼 때는 조금 다른 것 같습니다.
• 맛집 이라는 맥락은 원격에서 가져온 가게 데이터에 기반하는 derived data 일 것입니다.
• UI Tree의 거의 최상단에서 부터 흐르는 맥락으로 보이네요. 이 맥락이 상단 검색창이나 화면 구석구석에서 사용되는 것으로 보입니다.
• 더 정확히는 "맛집을 선택한다" 라는 사용자 이벤트가 맥락으로 존재합니다
• 이 맥락을 통해 앱의 다양한 유즈케이스가 추가로 정의됩니다.
이 경우에는 단순히 새로고침하면 없어져도 된다고 해서 "휘발성" 맥락으로 취급하기 힘들다고 생각합니다. 영구적이진 않아도 라이프사이클이 꽤 넓은, 고쳐 말하면 순수하게 UI 에 국한된 정보(모달이 열렸는지 닫혔는지 같이)가 아니잖아요. 이럼 react context를 만들어 쓴다 쳐도 어차피 거의 최상단에 위치하게 됩니다.

캐시 사용은 정확히 이럴 때 고려되면 좋을 것 같습니다. 말씀하신거 처럼 graphql client 들의 cache 는 다른 상태관리자들의 store 와 관리 주체를 제외하고는 개념이 동일하고 구현도 유사하기 때문에 여러 개 사용할 필요 없이 apollo client를 사용하셔도 됩니다.

mobx 를 쓰냐 마냐는 그냥 API 취향일거같긴 한데요 apollo client 로 관리할 때의 특징을 짚어드리면

schema 기반이고 선언적으로 다루는 정도가 장점일수도 단점일수도 있습니다 (말씀하신대로 스키마 선언하고 @client 쿼리 만들고 하는게 말이죠)

근데 사실 apollo inmemory cache 는 그냥 스토어 쓰듯이 readData, writeData 하면서 써도 잘 돌긴해요

React도 Apollo도 그닥 권장하는 패턴은 아닙니다

&gt; 예를 들어 컨텍스트나 mobx 에다가 선택된 맛집 object 를 통째로 넣고 있으면 refetch 될 때 맛집 정보가 바꼇더라도 컨텍스트나 mobx 는 그걸 모르니까 re-render 를 위해 object 를 컨텍스트나 mobx 에 다시 갈아끼워 넣어야 할 것 같은데, 컨텍스트나 mobx 에서 선택된 맛집 id 만 들고있고 각 컴포넌트가 apollo-client-cache 에서 id 로 맛집 object 를 들고와서 랜더하고 있다면 refetch 시에도 알아서 re-render 가 될 것 같습니다.
변경은 잘 감지합니다. apollo client api 로 가져온 슬라이스는 전부 불변객체이라 내부 모양이 바뀌면 참조가 바뀌어요

즉, 알아서 구독하고 re-render 합니다. 외부 스토어가 추가로 있다면 참조가 바뀌었을 때 메시지만 쏘면 (action dispatch) 되겠죠

&gt; pollo-client 랑 mobx 랑 두 곳에서 상태관리를 하고 렌더링을 observe 하고 있는 게 깔끔하지 않은 느낌도 들어서 apollo-client 로 통일해야겠다는 생각도 들구요.
장기적으로 코드 뿐만 아니라 양쪽 동기화를 사용자 코드로 하는 것이기 때문에 일관성까지 깨먹을 위험이 있습니다. 역할이 겹쳐서요. 같이 쓰려면 역할을 잘 나누어 격리해야 하고, 아니라면 한쪽으로 밀어버리시는 걸 추천드려요

감사합니다. 뭔가 감이 올 거 같아요. 설명해주신 내용이 뭔가 꽤 큰 graph 를 다룬 경험이 있어야 알 수 있는 것들 인 것 같아서 graphql 다룬지 얼마 안 된 저한테 큰 도움이 될 거 같습니다.

이거 정말 궁금하네요. ㅠㅠ 네임스페이스 기능이 없어서 전 서비스 이름을 프리픽스로 붙여주고 있어요.

프론트엔드 개발자들 입장에서는 짜증날수있겠네요 ㅋㅋ

혹시 여러개의 Prisma 서버도 hasura의 remote schema로 합칠 수 있나요??

apollo faderation이나 client side 에서 스티칭 해서 쓰는게 맞겠죠

저는 “클라이언트는 항상 하나의 데이터 그래프에만 의존한다“를 컨셉으로 밀고 있어서 쿼리에 네임스페이스(프리픽스) 노출하는건 지양하는 편

Hasura 는 자체적으로 스티칭은 지원 안하나 보군요

faderation 랑 스티칭 좀 찾아보겠습니다.

동일한 스키마 타입이라도 프리픽스로 주고 관리하시나요?