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

GraphQL Korea

왜인지가 중요할거같네요 ㅎㅎ 만약에 특정한 오류로 인한 상황이 아니라  내부 도메인 정의에 따라 나누어지는 상황이라면 (여쭤보신 케이스는 이 케이스 같네요) `union` 타입이나 `interface` 로 분리하는게 좋을거같아요.

```query {
  user {
    __typename
    password

    ... on UserWithEmail {
      email      
    }
    ... on UserWithAddress {
      address
    }
  }
}```


Union:
```union User = UserWithEmail | UserWithAddress

type UserWithEmail {
  email: String!
  password: String!
}

type UserWithAddress {
  address: String!
  password: String!
}```
Interface:

```interface User {
  password: String!
}

type UserWithEmail implements User {
  email: String!
  password: String!
}

type UserWithAddress implements User {
  address: String!
  password: String!
}```


최대한 클라이언트에서 요청한 데이터 형식으로 만들어서 보내주는군요.

감사합니다 :slightly_smiling_face:

어떤 종류의 라이브러리를 찾으시는지 잘 모르겠습니다.

Nexus, TypeGraphQL 등 framework를 알아보고 있었어요

TypeORM 등의 ORM 정의와 GraphQL 스키마 선언은 따로 분리하시길 강력히 권해드립니다 ㅎㅎ 아무래도 ORM 정의랑 스키마 선언이 붙어있다보면 스키마 선언과 실제 구현이 붙어다니게 되는데요 ㅠ 구현 이전에 스키마 리뷰를 통한 팀내 개발자 (특히 프론트엔드) 와의 원활한 생각 Sync를 위해서 분리를 추천드립니다.

<@UN0GLRW14>
아 최근에 고민하던 내용인데, 보통 분리 하는군요…감사합니다.

"보통" (많은 개발자분들이) 분리하는건 아닌거같아요 ㅎㅎ 근데 저는 분리하고, 스키마 논의를 활성화하는걸 권장드리는 편이에요.

필드명이나 이런것들에 대해서 개발전에 건강하게 논의할 수 있다고 판단해서요.

예를 들면... 프론트엔드 개발자로써 API 응답에서 필드명이 이상한 경우라던지 이럴때 피드백을 드리기가 참 애매하고, 자칫잘못하면 건강하지 못한 토론이 될 경우가 생기는데, 이런걸 미리미리 설계/논의 단계에서 캐치할수있어요.

ex:
• FE: 이거 필드명이 좀 이상한거같아요. 이게 더 낫지 않아요?
• BE: ;;; (이미 DB 마이그레이션 까지 다 돌려놓고 올려놨는데...) 음... 바꾸기가 좀 힘들어서... 그냥 가시죠
• FE: 그래도 이건 아닌거 같아요.
• BE: ...음....

저같은 경우에는 graphql 스키마와 prisma model 스키마를 동기화하는 것이 더 맞다고 생각했는데,

이렇게 되었을 때 graphql 스키마 맞추느라 불필요한 데이터가 클라이언트까지 가게 되더라구요..

GraphQL을 사용하시면서 얻을 수 있는 커뮤니케이션 적인 장점이에요

&gt; 불필요한 데이터가 클라이언트까지 가게 되더라구요..
이것도 맞구요

그리고 유비쿼터스 랭귀지 관점에서도 DB단과 맞닿아있는 CRUD보다는 비즈니스 랭귀지로 표현하는게 더 좋아요.

```type Mutation {
  # Don't
  updateUser(...): ...

  # Do
  registerNewEmail(...): ...
}```

흠 문제없이 사용가능한걸로 알고 있어요

네 그것이 React Native의 장점이죠 ㅎㅎ Facebook에서 실제로 개밥먹기하는 스택인걸로 알고있어요.

제가 지금 슬쩍 해봤는데,
• react-relay
• relay-runtime
• babel-plugin-relay
• relay-compiler
• relay-compiler-language-typescript
• relay-config
모두 react-dom 의존성 없네요 (심지어 react 의존성도 없습니다)

혹시 어떤부분 확인하시고, react-dom 의존성있다고 생각하신건지 여쭤봐도 될까요?

<https://relay.dev/docs/getting-started/installation-and-setup/#installation>
문서에 react-dom도 같이 설치하라고 되어 있길래 뭔가 의존성이 있나 궁금했어요 ㅋㅋㅋ
생각해보면 dependencies나 peerDependencies로 없으면 상관 없겠군요..

+) 리액트 네이티브와 relay를 같이 사용하는 레퍼런스가 많지 않아서?

&gt; 리액트 네이티브와 relay를 같이 사용하는 레퍼런스가 많지 않아서?
페북 내부에서나 생태계에서 많을거 같은데요 ㅎㅎ GraphQL을 모바일에서 잘 쓰려면 RN이 유일해서요. (Relay만한 클라이언트가 없어서...) 제가 봤을때는 문서가 잘못된거같네요 ㅋㅋ 뭔가 컨텍스트가 있으려나...

&gt; 페북 내부에서나 생태계에서 많을거 같은데요 ㅎㅎ GraphQL을 모바일에서 잘 쓰려면 RN이 유일해서요. (Relay만한 클라이언트가 없어서...)
저도 그렇게 생각해요..ㅋㅋㅋ relay목적이 RN을 위해서인걸로 알고 있어서..
그런데 RN쪽에서 GraphQL 리소스가 Apollo에 관한게 더 많은거 같네요..

Apollo 유저가 많다보니 그런듯해요 ㅋㅋ 저는 Relay가 훨씬 좋다고 생각... ㅎㅎ

지역화/국제화 서비스 엄청 타거든요,, 좀더 설명 자세히 해주셔야 프랙티스 추천이 가능할 것 같네요

어떤 서비스이고 어떤 구성이고 어떤 도구를 사용하시는지

`gatsby-theme-i18n` 과 `gatsby-theme-i18n-react-i18next` 을 설정해서 예를 들어 아래와 같이 라우팅이 되게 설정 했습니다. (gatsby-theme-i18n 이 onCreatePage 를 이용해서 `ko` prefix 를 붙여서 페이지를 자동으로 만들어주더군요) 문제는 `fruits` 데이터가 rest api 인데 i18n 이 없을때는 `sourceNodes` life cycle 에서 rest api 를 fetch 해서 `createNode` 안에 넣어줬는데, `ko` 의 경우에는 어떻게 처리해야하는지 궁금하네요. Runtime 으로 Fetch 하면 간단하겠지만, 가능하다면 build time 에 처리 하고 싶습니다.
특정 페이지만 자동으로 `ko` prefix 를 주소에 추가해서 페이지를 생성하는 걸 skip 하게 할 수 있을까요?
```/ : en 홈
/fruits
/fruits/:type
/fruits/detail/:id

/ko : ko 홈
/ko/fruits
/ko/fruits/:type
/ko/fruits/detail/:id```

<https://github.com/gatsbyjs/themes/blob/1ddd07c4248239e6323833c6d6d572ac0a0d57a1/packages/gatsby-theme-i18n/gatsby-node.js#L132-L172> 여길 보니까 아마 `page.context.originalPath` 에 어떤 값을 주면 자동으로 locale 별로 페이지를 추가 해주는게 실행되지 않을것 같은데 이렇게 하면 될까요?

사용하신 플러그인 디테일은 잘 모르겠습니다. locale 이 여러개인데 이걸 path context 에 넣지 않고 싶다는 말씀이신가요? 그렇게 하고자하는 이유가 있나요?

정적으로 볼 수 있는 page context 가 없으면 (여기선 URL) 당연히 런타임에 모든 로케일에 대한 정보를 들고 계셔야합니다

GraphQL 레벨에서 다 처리가 되는 문제였네요. 언어 별로 node  만들어 놓고, pageContext 로 넘어온 locale 에 맞는 node 를 출력해주면 되는거 였군요 ^^;

아니면 프레임워크에서 제공하는 기능이나 유틸리티 만드셔도 되고요

GraphQL.js - <https://github.com/graphql/graphql-relay-js>

Nexus - <https://nexusjs.org/docs/plugins/connection>

언어 다른거 쓰시면 더 좋고요 보통 다른 동네들이 더 잘 되어있어요

으허.. 그렇군요 우선 graphql 찍먹좀 제대로 해보려고 합니다

ㅋㅋㅋ그러다 체하지 않을까요

에이 뭘 괜찮을거에요~ (무책임)

여기가 뭐 원투이어도 아니고요

graphql-relay-js 는 직접 SDL 을 선언한 뒤에 활용할 수 있는 라이브러리인가요?

그 약간 셀프 체끼를 얹는 느낌인데 makeExecutableSchema 인자로 schemaTransform 이라던가 하는 것으로 SDL 도 자동으로 작성되게 하는 접근도 가능한가요?

SDL 은 뭐 직접 디렉티브 핸들러 만드시면 됩니다 어렵지 않아요

날먹하고 싶으시면 Postgraphile 이나 Hasura 같은 생성기를 쓰셔도 되고요

얘네도 커넥션 이쁘게 잘 뽑아줘요

ㅋㅋㅋ 쓰레드 재밌네요 ㅋㅋㅋ

아 매운맛 좋아하긴 하는데 제가 고려중인 스코빌과는 거리가 좀 있네요

스키마 메타프로그래밍 하는거 생각하시는거보다 쉬워요

당근마켓 사무실 놀러오시면 제가 핸즈온 해드릴게요 ㅎㅎ

&gt; SDL 은 뭐 직접 디렉티브 핸들러 만드시면 됩니다
아마 이쪽으로 제가 디깅할 것 같은데요, 궁금한게(아니면 이해가 제대로 안된게)
graphql-tools 에서 제공한 것들 뚝딱뚝딱 사용해서 makeExecutableSchema 를 만들고 → 이걸 codegen 으로 타입 생성을 해 줄수도 있나요?

보시고 까먹으셨을 수도 있는데 제가 이주제로 발표했었으니 그걸로 갈음하겠습니다.

<https://www.youtube.com/watch?v=tVNOKT7xqPo&amp;t=3395s>

Untitled.ts

뭔가 되게 재밌네요 디렉티브를 만들어서 쓴다는 느낌이 넘나.. 신선합니다 쥐린이 해피
+ 여러번 시행 착오 하면서 작성한 코드인데 혹시 틀린 부분이 있을까요?.?

테스트해서 잘 되면 됐죠~ ㅋㅋ

오오... 잘 작동하면 나중에 패키지로 하나 빼주세여 ㅎㅎ

감사합니다. 깃랩도 있네요. 보니깐 컨벤션은 비슷한 것 같아요
<https://docs.gitlab.com/ee/api/graphql/reference/#querysnippets>

저는 요거 Complete package 구매하면 동봉되어있는 스키마 Cheatsheet도 참고 많이 하는거같아요 ㅎㅎ

<https://book.productionreadygraphql.com/>

오 저런것도 있네요…
안에 내용은 어떤가요 ?

UI가 바뀌면 분리하는게 깔끔할거 같아요

RPC 같은 개념으로 접근하신다면 GraphQL 은 적합하지 않습니다.

서비스 메시 개념으로써는 많이 활용되는 편입니다

• <https://www.apollographql.com/docs/federation/>
• <https://the-guild.dev/blog/graphql-mesh>
• <https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2>

오오! 참고해서 공부해보겠습니다!

RPC, 서비스 메시라는 개념이 저한텐 생소한 개념인데 어디에 가까운지도 파악해봐야 겠군요..
단순히 REST API로 데이터를 가공해서 제공해주는 형태이긴한데

잘못 읽었군요..
&gt; 저희팀은 여러팀에 REST API를 제공하고 있는 상황입니다.
요 부분을 놓쳤습니다 ㅋㅋ;

인하우스 서버에 GraphQL API 노출하는건 크게 문제될거 없다고 생각합니다

인하우스 서버가 요청을 그대로 포워딩한다면 문제가 될 수 있는데.. 적절히 캐시처리만 하셔도 될거구요

GraphQL의 장점은 "유연성"입니다. 아마 스키마만 조금 고민하시면 현재 처하신 문제는 해결될거라고 생각합니다. 하지만 유연성을 얻는 대신 원래 제공하던 커스텀 엔드포인트들에서 있던 처리의 효율성은 조금 희생하게 될 수도 있습니다.

아하… 그런 단점이 있긴하네요!
그런 단점이 있긴해도, 그 유연성이라는 장점이 너무커서 도입을 꿈꾸고 있긴한데, 많은 유관팀에서 같이 적용을 해줘야 하는 내용이라 어떻게 설득을 해봐야 할지 고민중에 있습니다!
좋은 의견 감사합니다~!

스키마가 도메인을 깔끔하게 정리해주는 건 장점이라고 생각하는데 mutation은 여전히 use case별로 customize하게 되더라구요

아하!! 좋은 의견 감사합니다!
mutation은 어쩔 수 없겠군요.. 수정보다는 조회가 많기도 하고, 조회만 어느정도 개선이 되어도 좋을 것 같아요
API를 요구사항마다 찍어줬었다 보니 중복도 엄청 많고 DTO 중첩구조도 어지럽고 여러모로 감당이 안되는 상황이네요ㅠ

흠... 제가 웅재님께 한번 여쭤볼게요

image.png

<@UN0GLRW14> 페이스북 링크 누르고 들어가면 연결되는 링크가 404인거 같아요! 번거로우실텐데 감사합니다!

계정 분리밖에 답이 없을거같네요 ㅠ

<https://github.com/graphql/graphql-relay-js#object-identification>

graphql-relay-js에 `fromGlobalId`, `toGlobalId`를 활용하시면 Base64 인코딩 통해서 숨길수있어요

감사합니다~ 백엔드 언어로는 Rust를 쓰던 상황이라 구현은 직접 해야겠네요

음 아직 뭔가 많이 만든 건 아니긴 하지만… 일단 GraphQL 쪽에선 인터페이스 생성 및 적용이 좀 불편한 것 빼고는 만족스러운 상태에요

&gt; schema가 서로 디펜던시가 있어서, 1개의 루트 스키마에 하위 필드들로 resolver chaining으로 연결된 상황이구요,
스키마 사이에 디펜던시가 있다는거랑 resolver chaining? 이 무슨 뜻인지 잘 모르겠어요 ㅎㅎ

&gt; watch, diff와 같은 함수를 실행하게 되어서 Next.js의 Node.js 서버에서 성능 이슈가 현저하게 떨어집니다.
혹시 flame chart로 확인하신걸까요?

&gt; 스키마 사이에 디펜던시가 있다는거랑 resolver chaining? 이 무슨 뜻인지 잘 모르겠어요 ㅎㅎ
아 1번의 graphql api 호출로 해당 페이지내 모든 데이터를 하나의 루트 스키마 하위로 가져올수 있는 스키마 구성입니다.

&gt; 혹시 flame chart로 확인하신걸까요?
넵!

흠... 이게 그 getDataFromTree에서 발생하는 부하인가요?

제 뇌피셜인데 데이터를 가져와서 캐시로 Normalize하는건 부하가 심하지 않을거같아서요

비추하는 상황이라서, 사용하고 있지 않씁니다

이거 모르겠네요 ㅋㅋㅋㅋㅋ 혹시 Flamechart 공유해주실수있나요? 그 export가 될거에요

Apollo가 Apollo 했는지, 유저가 잘못했는지 파악이 좀 필요할거같아요

저거 차트를 줘도되는지는 보안검수 한번 여쭤볼게요!

혹시 쿼리가 어느정도 무거운지 궁금한데 프로덕션 나가있는 페이지 하나 던져주실수있나요?

아 저희가 아직 프로덕션으로는 배포가 안되어서요 ㅋㅋ
프로덕션 전에 성능 테스트중입니다 ㅠㅠ

아하... 음 만약에 공유하시는게 힘드시면 재현가능한 경로가 필요할거같네요.

&gt; 성능 이슈가 현저하게 떨어집니다.
저도 궁금하네요. 이거 크리티컬한건데요 ㅠ Apollo보다는 Relay가 이런 이슈 안 겪고 믿고쓰기 참 좋은데...

ㅠㅠ 얼마전에 makeVar도 메모리릭이슈도 있었고.. 애매하네요

mappers 옵션 보시면 됩니다 ㅎㅎ 특정 Object Type을 TypeScript Type/Interface와 연결할수있어요

&gt; graphq-code-generator에서도 위에서 처럼, 해당 필드의 resolver가 구현되어 있는지 확인할 수 있는 방법이 있나요?
이건 방법이 없습니다~

이거 찾아보니깐…하나씩 다 정의해줘야 하는 것 같은데..코드량이 장난 아닐 것 같네요.

보통 하나씩 다 정의해주나요 ?

1. useLazyLoadQuery
    a. 클릭 등 유저의 행동 -&gt; state 변경 -&gt; react 리렌더링 -&gt; query 호출 -&gt; 로딩 표현 -&gt; 완료
2. useQueryLoader
    a. 클릭 등 유저의 행동 -&gt; query 호출
    b.                                -&gt; state 변경 -&gt; react 리렌더링 -&gt; 로딩 표현 -&gt; 완료
요렇게 더 일찍 요청을 날릴 수 있어요. 그래서 react 리렌더링이 일어나는 10~20ms 정도의 시간을 아낄수 있어요.

<https://relay.dev/docs/guided-tour/rendering/queries/#fetching-queries-for-render>

onSelectHomeTab을 보시면 됩니당

```    // Start loading query for HomeTab immediately in the event handler
    // that triggers navigation to that tab, *before* we even start
    // rendering the target tab.
    // Calling this function will update the value of homeTabQueryRef.```

오오오 useLazyLoadQuery는 setState를 해서 리렌더링 이후 바뀐 상태를 통해 쿼리를 요청하게 되어서 약간 간접적으로 쿼리를 쏘는 반면,
useQueryLoader를 쓰면 직접적으로 loadQuery써서 쿼리를 날릴 수 있군요 ㄷㄷ
좋은 설명 감사합니다! 바로 이해되었어요!

useQueryLoader + loadQuery를 쓰는게 성능상 이상적이긴한데, 쿼리를 호출하는 곳과 쿼리를 소비하는 곳이 서로 멀리 존재하게 된다면 코드적으로 유지보수하기 힘들게 될거같아요. 그래서 대부분의 경우에는 useLazyLoadQuery를 쓰게되는거같긴해요

예1. 버튼을 눌렀을때, 페이지 이동, 이후에 데이터 로드 (useLazyLoadQuery)
예2. 버튼을 눌렀을때 하위 컴포넌트를 로드 (useQueryLoader)

그치만 react-router v6 에는 preload 기능이 새로 추가되는걸로 알고있어서… 이런 경우에는 페이지 이동시에도 useLazyLoadQuery를 쓸 수 있을것으로 기대하고 있어요 ㅎㅎ

오오오오 저도 useLazyLoadQuery가 더 직관적이고 사용하기 편한거같아서 10ms~20ms는 포기할만한거 같아요 ㅋㅋㅋ

예2에서 버튼 클릭시 하위컴포넌트 로드할 때 useQueryLoader를 선호하시는 이유는 그래도 버튼 클릭이라는 유저 액션에 대해서는 조금이라도 빠르게 렌더링을 해주고 싶으셔서 사용하시는걸로 이해하면 될까요?

render-as-you-fetch 패턴에 대한 맥락은 여기 추천드립니다.

• Concurrent UI Patterns: <https://reactjs.org/docs/concurrent-mode-patterns.html>
• <https://youtu.be/WxPtYJRjLL0>

<https://github.com/apollographql/apollo-cache-persist>

질문이 잘못전달 된거 같네요 ㅠㅠ
cache.writeQuery로 가능한것 확인하였습니다.
답변 감사드립니당

쿼리가 스키마 말씀하시는거죠?

좀 큰 변화는 1번으로 합을 맞춰서 진행하면 좋을거같고, 다른 것들은 2번으로 Parallel하게 진행하는게 좋지 않을까요?

Apollo Studio 같은 스키마 레지스트리를 활용하시면 특정 필드를 클라이언트가 사용하는지 따로 커뮤니케이션 없이 확인할 수 있어요.

네 스키마입니다.

상황에 따라 1,2번 방법을 선택하고 있는데… 지혁님은 어떤식으로 관리하고 계신가요 ?

저희는 웬만하면 2번입니다 ㅎㅎ

저희도 대규모 작업이 생길 경우엔 1번으로, 보통은 2번으로 진행하고 있습니다. 정답은 없고 상황에 따라 합의를 거쳐 진행해야 되는 것 같아요 ㅎㅎ

<@UN0GLRW14>
2번 작업이 프론트/서버 user -&gt; user2로 변경하고 user query삭제 후 user2의 이름을 user로 변경하는거 까지 말씀하시는 거죠 ?

<@U011MJ8J2GY>
답변 감사합니다 ~!
다른 분들은 어떻게 하고 있는지 궁금했는데, 비슷한 방법으로 진행하고 있는 것 같네요.

좀 더 유즈케이스가 구체적이면 좋을 것 같은데용..!

이 동네에서도 은총알은 찾지 못했습니다! :laughing:

이제 만드는 거라 앞으로 온갖 것들이 다 들어갈 예정이라 여쭤봤습니다 ㅋㅋ

cache-policy 정책이 여러개 있습니다.

<https://www.apollographql.com/docs/react/data/queries/#supported-fetch-policies>

Cache Policy 설정을 따로 하지 않는다면 기본적으로 cache-first 정책을 쓰기 때문에 앱이 살아있는 동안은 지속됩니다.

Apollo Client v3 부터는 GC가 구현되어 있기 때문에 완전히 도달 불가능해진 노드들에 대해서는 GC가 자동으로 되구요. 이 동작은 Type Policy 로 커스터마이징 할 수 있습니다.

<https://www.apollographql.com/docs/react/caching/garbage-collection/>

GraphQL 은 cache expiration에 대한 개념이 없어서 apollo에서도 시간을 따로 설정할 순 없습니다.

<@UN4AJARCN> <@UQ2PGQDHP> 도움 감사합니다!

흠… 혹시 로그인은 JWT를 localStorage에 담는 등의 클라이언트 기반 토큰을 쓰시나요 아니면 쿠키/세션을 쓰시나요?

토큰이 없을 떄 유저 정보를 가지고 오면 서버에서 권한 에러를 내니까 계속 에러 바운더리로 가더라구요

이걸 좀 나이스하게 핸들링 해보고 싶은데 어렵네요

```// 스키마
type Query {
  viewer: User
}


const query = useFragment(graphql`
  fragment Something_query on Query {
    viewer {
      id
    }
  }
`)

if (!query.viewer) {
  // ...
}```
요렇게 처리할수"는" 있을텐데요. 로그인 여부는 일종의 클라이언트 상태에 가까울것같아서, Relay 클라이언트의 캐시를 사용하는것보다 일반적인 전역 상태를 사용하는게 더 간편하고 용도에 맞을거같아요.

• Relay는 유저로부터 초래된 "상태"라기보다는
• 리모트 데이터를 캐시하고 변경을 전파하는 "데이터 레이어"라고
저는 봐요 ㅎㅎ

여기서 말하는 상태는 Finite State Machine의 그 State 입니다 ㅎㅎ

<@UN0GLRW14> 좋은 답변 주셔서 감사합니다!
말씀하신대로 사용자 상태를 데이터 레이어에서 분리하는게 좋겠네요!
한꺼번에 쓰려니까 개념이 혼재되었던 것 같아요. 감사해요! :pray:

```const data = [
  { id: '1' as const },
  ..
]

type A = typeof data['id']
```

as const 붙이시면 string 아니라 해당 값으로 추론되서 타이핑 될거에요 ㅎㅎ

<@U01HS6GJNF8> 확인하셨나요? ㅎㅎ

<@UN0GLRW14> 아 넵 값으로 잘 추론되는거 확인했습니다 감사합니다! 감사 인사 드리는 걸 빼먹었네요 :cry:

<@UN0GLRW14> 조금 더 고민해본 결과 최종적으로 제가 원하던 답변을 찾았습니다! 감사드립니다!

보통 GraphQL Server introspection에 GraphQL Code Generator 같은거 구성해서 써요

<https://www.graphql-code-generator.com/>

&gt; 서버의 Graphql Scheme 업데이트에 따라서 Client(React)에서 자동으로 Scheme 업데이트
<@U02EZTZ1MFW> 클라이언트에서 스키마를 업데이트한다는게 어떤 맥락에서 나온 니즈인지 궁금해요~

React에서 Graphql을 호출할 때 String을 활용해서 Query를 호출하고 있는데요. 단순 String을 사용하는 게 비효율적인 것 같아서요. 가령 서버에서 `User Type`에 새로운 속성 `age`가 추가되었다고 하면 React에서 자동으로 `age` 속성이 추가되었다는 걸 인지할 수 있도록 하고 싶었습니다.

그럼 코드젠 사용하면 되실거같네요 ㅎㅎ 클라이언트는 Apollo Client 쓰시는거죠?

네넵 맞습니다. 감사합니다 혜성님, 지혁님~! :pray:

Opinion: DB 레이어하고 API 레이어의 언어, 추상화는 분리하는게 더 좋아요 ㅎㅎ 저희는 GraphQL 스키마는 다 손으로 적고, 타입만 생성해서 써요 (graphql code generator)

답변: 질문 주신건 postgraphile이나 graphql-mesh의 mongoose 플러그인 같은거 보시면 될거같아요. (앞서 이야기했듯이 추천드리진않아요 ㅎㅎ)

해당 기능을 저희는 직접 module로 만들어서 컨트롤해왔었는데 다른 분들은 어떻게 컨트롤하시나 궁금했어요. 혹시 DB와 API 레이어를 분리해서 관리하는 것이 더 좋은 이유를 조금 더 알려주실 수 있을까요~??

릴레이에서는 Mutation 후에 리스트 앞 뒤로 붙여야할때 @appendEdge, @prependEdge, 혹은 리스트에서 삭제해야할때 @deleteEdge 등 기능을 지원합니다 ㅎㅎ

Apollo 도 Pagination Util 이 있긴 합니다.

<https://www.apollographql.com/docs/react/pagination/core-api/>

<@U02LGEUBT28> 답변이 되셨을까요??

&gt; mutation 후 invalidate할 때 캐시를 잘 관리하는 게 쉽지 않았습니다.
요거 정확한 시나리오가 궁금한데 혹시 알려주실수있을까요? 왠지 오해가 있을거같아서 자세히 설명드리고 싶습니다

앗 제가 알림이 안와서 답변 달아주신 걸 방금 알았습니다. :sweat_smile: 시나리오 좀 정리해서 추가 코멘트 달아보겠습니다. 

<@UN0GLRW14> <@UN4AJARCN> 저는 페이지네이션 자체보다는 목록 안의 이이템을 추가/삭제하는 mutation 후 목록을 효율적으로 갱신하는 문제에 대해 다른 분들의 경험이 궁금했습니다. (1년도 전에 고민한 주제이고 지금은 react-query가 메인이라.. 기억을 좀 되살려볼게요 ㅎㅎ)

mutation 후 되도록이면 graphql 쿼리 요청을 줄이고 유저에게 즉시 결과를 보여주고 싶기 때문에, 목록 쿼리를 refetch하기보다는 <https://www.apollographql.com/docs/react/data/mutations/#include-modified-objects-in-mutation-responses|응답을 캐시에 바로 업데이트>하고 싶었습니다. (refetch 호출도 귀찮고)
그런데 apollo client는 업데이트 mutation은 result의 응답 결과를 자동으로 캐시에 업데이트해주지만 add, delete는 자동 업데이트를 안 해줍니다.
이 때는 cache를 manual update 하는 방식을 apollo가 제시하지만, 문법이 아주 직관적이지는 않고 목록이 깊은 위치에 존재할 때는 정확히 업데이트를 하는 것 자체가 힘들었습니다. 또한 유저에게 마지막으로 캐시된 목록에서 diff만 캐시에서 반영해주는 게 두 부분에서 부정확할 수 있다고 봤습니다.
1. 다른 유저의 행위에 의해 목록의 구성이 바뀌었을 수 있음
2. 아이템을 추가했을 때는, mutation 결과를 어디에 붙여넣을지 클라이언트가 정렬 순서를 정확히 알고 있어야 함(목록 맨 앞? 맨 뒤? 만약 정렬이 시간순이 아니라면?)
그래서, 대신 mutation의 응답 결과에서 목록 전체를 다시 쿼리해오는 방식을 사용했습니다. 그러나 이 방식 또한 한계가 있었는데,
1. 전체 목록을 다시 가져오기 때문에, 목록을 쿼리해오는 게 무겁다면 유저가 mutation 응답을 받아 결과를 보는 것 자체가 오래 걸린다 
    a. -&gt; optimistic UI를 고려는 했었지만 실제 적용까지는 안했습니다
2. 페이지네이션이 이미 되어있는 목록을 이 방식으로 가져오기가 까다롭다. (mutation에서 리페치해올 오프셋 지정을 안 하면 첫 페이지 크기만큼만 가져올텐데, 그렇다고 오프셋을 지정하자니 mutation의 책임이 아니고..) 
    a. -&gt; 이 문제는 실제로 자주 발생하지 않았기 때문에 무시했고, react-query에서는 InfiniteQuery가 애초에 일반 쿼리와 구분되어 있어서 invalidate하면 기존 캐시에 있는 것들을 순차적으로 업데이트해주길래 편했습니다.
이런 일을 겪고 나니 normalized cache 가 편하기도 하지만 불편하기도 해서, 지금은 react-query를 메인으로 쓰고 있습니다. 써보니 API 호출 횟수를 줄이는 것보다는 캐시 관리가 편한 게 더 낫다는 생각이 들었습니다.

```query {
  articles {
    id
    title
  }
}

mutation UpdateArticleTitle($id: ID!, $title: String!) {
  updateArticleTitle(input: { articleId: $id, title: $title }) {
    article { // 아폴로 캐시의 articles에 해당 id 값의 title이 자동 업데이트됨
      id
      title
    }
  }
}

mutation RemoveArticle($id: ID!) {
  removeArticle(input: { articleId: $id }) {
    query { // mutation 응답에서 목록을 다시 불러옴
      articles {
        id
        title
      }
    }
  }
}```

&gt; InfiniteQuery가 애초에 일반 쿼리와 구분되어 있어서 invalidate하면 기존 캐시에 있는 것들을 순차적으로 업데이트해주길래 편했습니다.
네 이게 Pagination 이 대표적으로 데이터 그래프 모델링할 때 다루지 않고 클라이언트에서 추상화되어야 하는 순수 UI 로직이라서 그런데요. 말씀하신거처럼 유틸리티를 만들어서 대응하고 Apollo Client 에서는 주로 Type Policy 에서 정책을 재사용하는 식으로 다룹니다. 저 같은 경우는 전에 Apollo Client 2 쓸 때 요청 크게 나가는게 싫어서 Offset 맥락을 따로 관리했던 기억이 있네요.

Pagination은 다른 라이브러리 쓸 때도 대체로 비슷할거에요 ㅋㅋ 라이브러리가 직접 지원하면 좀 애매한게 사례가 딱 맞으면 편하긴 한데 보통 커스터마이징이 살짝씩 들어가기도해서 아폴로 쓸 때도 굳이 편하게 만드려고 노력은 안했었네요.

그렇군요. 답변 감사합니다. :slightly_smiling_face: 저도 아폴로 v3가 너무 안나와서 오랫동안 v2까지만 썼었는데 혹시 이제 더 괜찮아졌나, 하는 기대도 있었는데 그건 아닌가보네요. 
(그나저나 쓰레드 알림이 안올까요..ㅠ 알림 설정에는 문제가 없는데..)

아 그래도 오프셋 기반 커넥션 기반 각각이 페이지네이션 기본 유틸이 있어서 Apollo 2 때보단 많이 낫습니다 :)

페이지네이션 관련해서는 혜성님이 잘 답변해주셔서 의문이 좀 풀렸는데요. 목록을 mutation 후 갱신하는 프랙티스에 대해서는 relay에서, 또는 다른 회사에서 어떤지는 아직 궁금하네요. 혹시 <@UN0GLRW14> 답변해주실 수 있을까요?

```      mutation PageReviewsDeleteReviewMutation(
        $reviewId: ID!
        $connections: [ID!]!
      ) {
        deleteReview(input: {
          reviewId: $reviewId,
        }) {
          __typename

          ...on DeleteReviewOutput_Result {
            result {
              reviewEdge {
                node {
                  id @deleteEdge(connections: $connections)
                }
              }
              widget {
                ...ProfileReviews_widget
              }
            }
          }
          ...on DeleteReviewOutput_WidgetNotFoundError {
            widgetNotFoundError {
              message
            }
          }
          ...on DeleteReviewOutput_ReviewNotFoundError {
            reviewNotFoundError {
              message
            }
          }
          ...on UnauthorizedError {
            unauthorizedError {
              message
            }
          }
          ...on UnknownError {
            unknownError {
              message
            }
          }
        }
      }```
delete 할때는 이렇게 하구요 ㅎㅎ append, prepend할때는 마찬가지로 `@appendEdge` `@prependEdge` directive를 쓰면 relay가 자동으로 붙여줘요.

append, prepend가 아닌 방식으로 업데이트해야 할 때는 없으셨나요? 제가 위에 썼던 부분을 다시 적어보면:

유저에게 마지막으로 캐시된 목록에서 diff만 캐시에서 반영해주는 게 두 부분에서 부정확할 수 있다고 봤습니다.
1. 다른 유저의 행위에 의해 목록의 구성이 바뀌었을 수 있음
2. 아이템을 추가했을 때는, mutation 결과를 어디에 붙여넣을지 클라이언트가 정렬 순서를 정확히 알고 있어야 함(목록 맨 앞? 맨 뒤? 만약 정렬이 시간순이 아니라면?)

&gt;  다른 유저의 행위에 의해 목록의 구성이 바뀌었을 수 있음
이건 해당 유저에게는 중요한 변경사항이 아닐수있어요. 유저가 "바라보는 세상"의 일들만 Consistency가 맞으면 됩니다 ㅎㅎ (그게 DB와 100% 싱크를 맞출수는 없어요. 만약에 그걸 원하시면 Subscription을...) 만약에 그정도로 중요한 실시간 변경사항이면 구현하셨던것처럼 refetch나 Subscription으로 받는게 맞을거같네요.

근데 이건 Normalize된 캐시라서 더 어려운 문제는 아닐거같아요.

&gt; 아이템을 추가했을 때는, mutation 결과를 어디에 붙여넣을지 클라이언트가 정렬 순서를 정확히 알고 있어야 함
넵 이건 맞습니다. 다만, 정렬 순서랑 관계없이, 일반적으로 유저가 작성한 콘텐츠는은 맨 위 (ex: 페이스북 피드) 또는 맨 아래 (ex: 채팅) 에 가는게 일반적입니다. 페이스북 피드는 시간 순서가 아니지만 유저가 글을 쓰면 맨 위로 올려주죠. 정렬보다는 유저의 탐험 경험과 연관이 더 많을거같아요.

리스트 중간에 추가한다던지 하는 경우는 저는 여태까지 경험을 못해봤네요;; 지금 당장 떠오르는 Use case는 상단 고정 게시글이 있다고 했을때 그 밑에 꼽는건데요. 위쪽 고정 게시물은 따로 처리하고, 그 아래부터 connection으로 간주하면 마찬가지로 쉽게 구현할 수 있을거같아요.

<https://relay.dev/docs/principles-and-architecture/thinking-in-graphql/#dataview-consistency>

답변 감사합니다. :slightly_smiling_face:
&gt; 유저가 "바라보는 세상"의 일들만 Consistency가 맞으면 됩니다
이 말씀이 잘 와닿네요. "정렬보다는 유저의 탐험 경험" 이라는 말씀과도 잘 연결이 되는군요.

희한하네요;; network 탭에서는 이미 오른쪽에 있는 순서로 와있는 거죠? 아마 resolver 단에서 한번 정렬을 때리지 않았을까요?

문제 해결했습니다. 일부 코드가 일치하지 않아서 빌드 과정에서 문제가 발생했었네요 ㅎㅎ;;

원래 질문을 올리고 나면 그때서야 해결이 되는거같아요 ㅎㅎ 수고 많으셨네요 ㅋㅋ

Apollo Studio 쓰고 Datadog tracer도 써요 ㅎㅎ

apollo studio는 대부분 다 사용하시네요, Datadog tracer는 어떤 용도로 사용하시는 건가요 ?

다른 마이크로서비스들까지 이어지는 Tracing을 보려고 사용해요 ㅎㅎ

혹시 apollo studio, datadog tracer 두 개 performance tradeoff 있는편인가요?

당연히 있겠죠? ㅎㅎ 그런데 크지는 않은거같아요. 저는 퍼포먼스 개선을 위해서는 Traceability가 더 중요하다고 생각해요. (측정해야만 개선할 수 있으니까요)

nodejs 쓰신다면 datadog 사용하실때 nodejs 버전을 적어도 14버전(지금 lts가 16버전이라서 이거 쓰시면 좋을거 같아요)이상을 쓰고 <https://github.com/DataDog/dd-trace-js|dd-trace-js>(datadog js client)도 최신버전 쓰는게 좋더라고요. 예전에 제가 node12 버전에서 쓰다가 이벤트루프가 1초이상 blocking되는 현상이 있더라고요.

12가 아직 유지보수 LTS라서 혹시나 해서 남겨봐요~

<@U018W3L7XCZ> 혹시 캡쳐하신 event loop delay 는 어떻게 수집해서 보고계신가요?

<https://clinicjs.org/doctor/>
이런 툴을 사용했어요

로컬에서 돌려볼때 <https://k6.io/>와 같이 사용했어요~
이게 부하테스트라면 실제 환경에 배포해서 하면 좋은데 부하테스트 보다는 프로파일링에 가까워서 로컬에서 해도 상관이 없을거에요

저기 clinicjs에서는 doctor외에 flame같은거 사용해보면 꽤나 쉽게 flamegraph를 볼수 있어서 좋더라고요~

요즘에는 많이 해결이 되었지만 작년에 저희 회사에서 datadog쓰는데 이게 계속 이벤트루프를 blocking하는 이슈때문에 간헐적으로 레이턴시가 튀는 현상이 있었는데 datadog한번 붙이실때 저걸로 프로파일링 한번 해보고 배포하는것을 추천드려요!

datadog이 tracing하는거 자체가 이벤트루프를 점유하기 때문에 datadog플러그인 잘못쓰면 문제가 생길거 같더라고요

graphql-codegen 거의 많이 쓰는 것 같아요

저는 위치는 컴포넌트 옆에 바로 생성되게 하고 있습니다 near-operation-file 프리셋 설정을 해서요

<@U01DQ1RSS93> <https://www.graphql-code-generator.com/plugins/near-operation-file-preset> 이 링크 말씀하시는게 맞을까요?? 제가 아직 이 방식 자체의 컨셉이 잘 와닿지 않아서 컴포넌트 옆에 생성된다는게 조금 이해가 안되기는 하는데 한번 직접 해보겠습니다! 추천 감사드려요! :bow:

넵 디폴트로는 graphql.tsx 같은 파일 하나에 서버 schema 와 사용된 Operation 에 대한 generated type 과 query mutation 등이 전부 들어가게 되는데 나중에 몇십만 라인까지 커지게 되면 에디터에서 굉장히 느려지더라구요. 초반에는 그냥 써보시고 필요하시면 적용하셔도 될 듯 합니다

<@U01DQ1RSS93> 오 그렇군요 감사합니다!
한 가지만 더 여쭤봐도 될까요? 현재 프로젝트에서 호출해야 하는 백엔드 서버가 2가지인데, 각각 스키마가 다르게 구성되어 있습니다. 호출하는 서버에 따라 폴더를 나누어 파일을 관리하신적이 있으실까요?

네  codegen.yml 파일 내에서 generates: 옵션 하위에 per output 레벨로 구성해서 각각 schema옵션을 먹일 수 있습니다 예를 들어서

```generates:
  generated/graphql.tsx:
    schema:
      - <http://localhost:5000/graphql>
    documents:
      - ...
  generated/graphql2.tsx:
    schema:
      - <http://localhost:3000/graphql>
    documents:
      - ...```

너무 많은 도움이 되었습니다! 감사드려요! :bow:

&gt; 별도의 타입을 작성해주는 작업이 이중작업이라고 느껴져 찾아보던 중 스키마에 맞춰 타입을 gen 해주는 라이브러리가 있다는 사실을 알게 되었습니다.
코드젠의 축복을 이제서야 아시게 되셨군요... ㅋㅋ

&gt; 현재 프로젝트에서 호출해야 하는 백엔드 서버가 2가지인데, 각각 스키마가 다르게 구성되어 있습니다.
스키마 스티칭이라는 솔루션도 있습니다~ (여러개의 스키마를 하나의 스키마로 합쳐줌)

<https://www.graphql-tools.com/docs/schema-stitching/stitch-combining-schemas>

번들사이즈가 커서;;; 클라이언트에서 사용하기는 좀 무리가 있는데 혹시 필요하시면 도입해보셔도 좋을거같습니다. (사실 저희는 클라이언트에서도 쓰고있어요)

```const schema = stitchSchemas({
    subschemas: [
      {
        schema: remoteSchema1,
        async executor({ document, variables }) {
          // ...
          return data
        },
      },,
      {
        schema: remoteSchema2,
        async executor({ document, variables }) {
          // ...
          return data
        },
      },
    ],
  })```


<@UN0GLRW14> 오 혹시 만약에 타입 이름같은게 겹치면 특정 네이밍룰로 자동 변환되나요 ?

네임스페이스 옵션이 있을거에요 ㅎㅎ

<https://www.graphql-tools.com/docs/schema-stitching/stitch-combining-schemas#adding-transforms>

RenameTypes 보시면 될거같아요~ ㅎㅎ

오! 스키마 스티칭이라는 개념도 있군요 처음 알았습니다 ㅎㅎ 감사해요 :pray::pray::pray:

저희가 apollo 사용하고 있는데 혹시 apollo-tooling에서 제공하는 codegen 기능은 추천하지 않으시나요?? <https://github.com/apollographql/apollo-tooling#code-generation>

<https://www.apollographql.com/blog/tooling/apollo-codegen/typescript-graphql-code-generator-generate-graphql-types/>

&gt; 저희가 apollo 사용하고 있는데 혹시 apollo-tooling에서 제공하는 codegen 기능은 추천하지 않으시나요??
넵 graphql-code-generator가 훨씬 좋습니다

Apollo가 잘 못 만들어요 (속닥속닥) ㅠ

와 한번 해보니 graphql-code-generator는 hook까지 만들어주네요;; 감사히 잘 쓰겠습니다

<@U01HS6GJNF8> fragment까지 꼭 사용해보시길 바래요~~~

Nest.js는 오피니언이 쎄서 문서만 읽어도 충분하지 않나요?? ㅎㅎ

어떤걸 기대하시는지 궁금해요

Nestjs는 3-tier architecture를 지향하는데 controller - service - data access(persistence) 요 3가지 레이어만 잘 신경쓰시면 될거같아요~ <https://medium.com/geekculture/nest-js-architectural-pattern-controllers-providers-and-modules-406d9b192a3a|참고링크>

지혁님이 말씀하신대로 공식문서에 아마 제가 보내드린 내용이랑 비슷하게 적혀있긴할텐데 중요한건 저걸 실제로 어떻게 나누는지는 어떤것을 개발하시느라에 따라 달라질거 같아요~

간단한 CRUD를 개발하면 사실 공식문서에 있는 example만 봐도 충분할거 같은데(Nestjs를 이용한 게시판 생성기도 있어요: <https://amplication.com/|링크>) 이제 점점 복잡하기 시작하면 Repository 패턴도 쓰고 비즈니스로직도 쪼개야하고(모듈단위로 쪼개셔도 되고 service를 여러개 만드셔도 되어요) 고민하실게 많아지실거 같아요.

이거 관련해서는 결국 Best Practice는 없고 Nestjs와도 상관없이 그냥 백엔드 아키텍처를 어떻게 만들까 하는 고민을 하게 되더라고요.

```documents:
  - 'src/**/*.tsx'
  - '!*.generated.ts'```
처럼 하시면됩니다. glob ignore path

오! 잘 되네요 감사드립니다 :man-bowing:

operation 들을 `.graphql`  파일에만 작성하는 방법도 있을 것 같아요,,! 확실하게 분리할 수 있어서

<@U01DQ1RSS93> 의견 감사합니다! 그 부분도 고민이 되는 부분인데요 이유는 다음과 같습니다
• 컴포넌트와 쿼리가 한 파일 안에 있으면 어떤 형태의 데이터가 사용될지 명확하게 파악할 수 있음. 하지만 사용하는 쿼리의 종류가 많아지면 관리가 애매해짐.
• .graphql 파일로 분리하면 operation을 분리할 수 있음 but 컴포넌트 하나에 컴포넌트 파일 + 스타일 + generate 파일 + graphql 파일 등 파일 수가 너무 많아짐

그렇죠 ㅎㅎ 거기다  +테스트 파일 까지 하면 진짜 많긴해요

<https://the-guild.dev/blog/graphql-codegen-best-practices> 저는 이 가이드 보고 나서 .graphql 을 쭉 하다가 팀에서 같은 파일에 놓자고 의견이 나와서 요즘엔 .tsx 에 포함시키고 있긴 합니당

아폴로 쓰시나요? fragment matcher 는 apollo client v3 에서는 안쓰이는걸로 알고잇어요!

네! 아폴로 v3 사용하고 있습니다. 그런데 해당 preset readme 보니까 apollo 3 버전에서의 사용 예제를 다루고 있는데 혹시 이 fragment-matcher 말씀하신게 맞으실까요?
<https://www.graphql-code-generator.com/plugins/fragment-matcher#usage-with-apollo-client-3>

```# RootComponent.tsx
import { FragmentSomethingWow } from './Something'

const RootComponent = () =&gt; {
  useQuery(graphql`
    query ... {
      ...Something_wow

      ${FragmentSomethingWow}
    }
  `)
}

# Something.tsx
import { Something_wow } from './__generated__/Something_wow.graphql'

export const FragmentSomethingWow = graphql`
  fragment Something_wow on Query {
    ...
  }
`

interface SomethingProps {
  wow: Something_wow
}
const Something = (props) =&gt; {
  return (
    &lt;div&gt;
      {props.wow...}
    &lt;/div&gt;
  )  
}```
이런식으로 못하려나요 ㅎㅎ Apollo를 안쓴지 너무 오래되서요 ㅠ

아 graphql-codegen fragment matcher plugin 이 스스로 possibleTypes 뽑는 기능까지 포함했나보군요

근데 실제로 필요한 내용은 이런 캐시 설정이에요

Apollo v2 에는 FragmentMatcher 라는 기능이 있어서 클라이언트에 알렸고 Apollo v3 에서는 Possible Types config 으로 대체되었는데

이전에 graphql-codegen 에서 쓰던 fragment matcher 생성하는 플러그인이 possible types 생성 기능까지 제공하나보네요

지혁님이 언급한 "Fragment 꼭 쓰세요" 랑 fragment matcher 는 다른데