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

GraphQL Korea

네네 만약에 더 궁금하거나 직접적인 도움이 필요하시면 또 남겨주세요 ㅎㅎ

스터닝님 질문덕에 커뮤니티가 풍성해졌네요! 질문 감사해요!

<https://www.apollographql.com/docs/react/local-state/reactive-variables/>

아 reactive var 도 만들어야 하는거군요 ??

<https://www.apollographql.com/docs/react/local-state/managing-state-with-field-policies/#storing-local-state-in-the-cache> 저는 여기서 구현을 reactive var &amp; cache 둘 중에 하나 고르는 그런 건 줄 알았는데

왜냐면 기존 GraphQL Schema 에다가 연장해서 필드를 추가하고 싶었거든요 Reactive Var 는 약간 remote state랑 완전 별개의 용도일때 쓰는 건 줄 알았어요

어쩌면 여기 나온 것 처럼 writeFragment 써야하는 걸지도 모르겠네요 <https://github.com/apollographql/apollo-client/issues/7814>

지금은 해결했습니다! 혜성님 댓글 주셔서 감사합니다 :man-bowing:

우선은 서버측에서 구현상 값이 언제나 있는 건 되도록 NotNullable 하게 줘야 할 것 같아요
클라측에서 할 수 있는 건 저도 궁금하네요 ..ㅎㅎ

GraphQL 스펙으로 논의되고 있습니다. Client-side nullability control

<https://mrtnzlml.com/docs/relay/directives#required>

<https://github.com/graphql/graphql-spec/pull/895>

뭐 일단은 가벼운 추상화로는 assert &amp; error boundary 같은 패턴도 있구용

```export function required&lt;T&gt;(v: T): asserts v {
  if (v == null) {
    throw new Error(`Expected non nullable, but got ${v}`);
  }
}```
```export default function MyComponent() {
  const data = useQuery(...);

  required(data.item.field);

  return (
    ...
  );
}```
```&lt;ErrorBoundary
  renderFallback={({ resetError }) =&gt; {
    return &lt;&gt;...&lt;/&gt;
  }}
&gt;
  &lt;MyComponent /&gt;
&lt;/ErrorBoundary&gt;```

Apollo Client 나 Urql 같은경우는 구문 확장할 수 있는 레이어가 존재하니 (각각 Link, Exchange)

직접 Client controlled nullability 구현해보시는것도 좋은 옵션일거같고

사실 fragment 를 잘게 쪼개다보면 nullability control 이 지저분해진다 싶을 정도로 길게 들어가는 경우가 드물어지는 것 같긴 해요

와 빠른 답변 감사합니다!! 저런 패턴도 있군요! fragment를 잘게 쪼갠다는 건, 컴포넌트별로 필요한 데이터(fragment)만 받아서 각각 예외를 확인할 수 있어서 드물어진단 말씀이신가요?

적당한 예시 바로 보여드릴게 있을지 모르겠는데, 대략 이런느낌으로 갑니다
<https://github.com/daangn/websites/blob/main/_packages/%40karrotmarket/gatsby-theme-team-website/src/pages/index.tsx>

fragment로 쪼개니 props 관리도 훨씬 깔끔해지네요! 예시 너무 감사합니다 :+1::+1:

<https://twitter.com/_philpl/status/1473647841247744002>

<https://yelp.github.io/graphql-guidelines/nullability.html>

GraphQL 필드 제거에 대해선 보수적인 게 좋은 것 같아요. @deprecated로 표시를 해놓고 차차 안쓰게 되는게 명확할 때 제거하심이?!

ㅎㅎ 감사합니다. 필드 제거뿐만 아니라 필드명 변경, input 타입에 필드 추가 등의 경우에서도 배포 이슈가 계속 발생해서 근본적인 해결책이 없을까 고민이 많이되네요 ㅠㅠ

필드명 변경보다는 오히려 새로운 필드를 추가하고, input 타입에 필드 추가는 nullable로, non-nullable이라면 default 값을 최대한 활용하는게 어떨까요? 근데 생각해보니 클라이언트에서 codegen을 통해 확인도 가능 할 것 같아요 ㅎㅎ

클라이언트에서 codegen을 통해 확인도 가능할 것 같다는게 어떤 말씀이신가요?

클라이언트에서 사용하는 쿼리 타입을 graphql code generator를 통해서 만들 수 있는데 이때 서버와 타입이 동일한지 확인하게 되거든요! 적절한 방식인지는 모르겠지만 ㅎㅎ <https://www.graphql-code-generator.com/>

근본적인 해결책은 스키마 변경을 최소화하고 변경이 있다면 해당 변경이 파괴적 변환을 발생시킬수있는지 잘 트래킹하는거겠죠? ㅎㅎ

제안: Apollo Studio에 Schema 변경시에 Breaking changes가 발생할 가능성이 있는지 체크해주는 “schema check”라는 기능이 있어요. 활용해보시면 좋을거같아요.

이건 GraphQL의 이슈라기보다는 스키마 변경이 잦은게 문제일거같네요. 일반 JSON API에서도 필드명이 변경되거나 삭제되면 에러가 발생하는것이 맞을거같아요.

Opinion: GraphQL은 오히려 스키마 변경 사항을 스마트하게 추적할수있는 기반을 제공해주기때문에 더 에러를 줄일 수 있습니다

Bumkeyy님이 제안해주신 GraphQL Code Generator가 그 도구중 일부구요

&gt; 그렇다고 매번 새로운 쿼리를 만들어서 버저닝을 하자니 조금 아닌거 같기도 하고…
&gt; 
이게 맞습니다. 시행착오를 조금 더 해보시면 스키마 설계를 좀 더 장기적인 관점에서 하시게 될 수 있을거에요 ㅎㅎ

&gt; input 타입에 필드 추가
&gt; 
input 타입에 required 필드 추가는 파괴적 변환이 맞습니다 ㅎㅎ

답변 감사합니다 ㅎㅎ 생각이 닿으면 닿을수록 말씀해주신대로 애초에 스키마를 좀 더 장기적인 관점에서 설계를 했으면 좋았겠다라는 결론이 나오더라구요. 좋은 의견들 주셔서 정말 감사합니다 :)

시행착오가 있는게 당연한거같아요 ㅎㅎ 저도 처음에 스키마 많이 갈아엎었고 고통스러웠던 기억이 있어요 ㅠㅠ (GraphQL이 별로인건가 고민했던 기억이 나네요 ㅋㅋ) 그치만 어느정도 노하우가 쌓이면 생산성을 훨씬 더 높일수있어요. 화이팅입니다!

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

요거 책 추천드립니다 ㅎㅎ

<@U01F8V81DE1> 예시를 볼 수 있을까욥???

컴포넌트 옆에 두는것이 가장 좋아요 ㅎㅎ 컴포넌트 선언 바로 근처가 저는 제일 좋다고 생각해요. Relay 한번 사용해보시죠~

예시: <https://relay.dev/docs/api-reference/use-fragment/|https://relay.dev/docs/api-reference/use-fragment/>

Relay에는 아예 useFragment 라는 기능을 제공하는군요! Apollo만 사용하다보니 ㅎㅎㅎ 예시 감사합니다!

안녕하세요~ 그냥 궁금해서 질문드립니다. 혹시 릴레이 도입을 검토하시는 이유가 있을까요? 있다면 알려주실수 있으신지요?

네트워크에서 페칭되는 데이터 관리가 안되고 있는 상황인데, 물론 apollo client 로도 가능한 것으로 알고 있습니다만, 프론트엔드 개발자분이 relay에 관심을 갖고 계셔서 … ㅎㅎ 이 그룹에 좋은 프랙티스가 많이 있을거 같아서 여쭤봤습니다.

으음 말그대로 넘긴 쿼리 객체가 GC 당했거나 mark 된걸로 보이네요

사용하신 코드를 같이 남겨주시면 좋ㅇ르거같은데

음 일단 컴퓨터가 앞에 없어서 코드 설명을 쭉 적다가 문득 클라이언트와 서버 각각에서 initialQueryRef를 먹여서 그럴 수도 있겠다는 생각이 들었는데요, 혹시 이게 문제일 수 있을까요? 아니라면 적던 걸 마저 적겠습니다...

일단 적던 걸 마저 적었는데요...
• `{ '/': indexQuery }` 식으로 각 라우트별 쿼리가 들어 있는 맵이 모듈로 존재합니다.
• 먼저 서버에서 이걸 가지고 `loadQuery` 해서 `initialQueryRef` 을 얻습니다.
• PageShell(최상단 컴포넌트)에서 Provider들을 씌운 후, 바로 안 컴포넌트에서 `useQueryLoader` 를 사용해 위에서 설명한 맵을 가지고 `{ '/': { queryRef, load(), dispose() } }` 식의 맵을 만듭니다. 활성화된 라우트의 경우 위에서 만든 `initialQueryRef` 도 사용합니다.
• 현재 활성화된 라우트의 컴포넌트에 해당 라우트의 정보를 가지고 `queryRef` 을 넘깁니다.
• 이후 Suspense 따라 SSR이 진행되고, 최소 대기 딜레이 내에 데이터 페칭이 완료되어 전체가 렌더링된 페이지가 클라이언트로 전송됩니다.
• 클라이언트 초기화 코드 실행이 시작됩니다. 서버에서 했듯이 활성 라우트 쿼리의 `initialQueryRef` 를 불러옵니다.
• 이후 서버에서처럼 PageShell을 사용해서 VDOM 노드를 만들고, Hydrate합니다.
• 로그로 찍어보면 최초 렌더 시에는 `queryRef.isDisposed` 가 false로 나오고, 즉시 `PreloadedQuery.releaseQuery()` 가 호출되며 true로 바뀌고 에러가 납니다.
코드 보고 싶으신 부분 알려주시면 이따가 시간 될 때 코드 올리도록 하겠습니다...

&gt; 클라이언트와 서버 각각에서 initialQueryRef를 먹여서
일단 테스트해 보니 이 경우는 아니네요… initialQueryRef이 없으면 에러가 나는군요

굳이 더 적은 필드를 가져올때의 쿼리 리졸버를 나누시려는 이유가 뭘까요??

SQL에서 select를 덜하기 위해서인가요?

네네 그렇습니다. 단편적인 예로 말씀을 드렸지만, 조금 더 복잡한 조인이 많을 경우에 불필요하게 리소스가 낭비된다고 생각했어요.

1. resolver 에선 최대한 lazy loading 하고 엔티티 프레임워크에서 알아서 잘 해결한다.
2. 데이터 로더에서 해결한다.
3. 런타임 정보(GraphQLInfo)를 분석해서 사례를 동적으로 나눈다
4. 미리 등록된 쿼리별로 SQL 을 컴파일 하는 식으로 사례를 정적으로 나눈다
스키마를 바꾸지 않고는 이런 접근법들이 있겠습니다.

나약한 소리지만… 답변 주신 걸 다 이해하진 못했네요ㅠㅠ
1, 4번은 클라이언트와 서버 간의 암묵적인? 약속인건가요? 클라에서는 id, title, imageUrl만 패치할거니깐 그것만 내려줘! 이렇게?

1번은 이미 서버에 있을수 있는 Data access layer 의 기능을 더 잘 활용하자... 이런거구요

3, 4번은 <https://github.com/join-monster/join-monster> 같은걸 말합니다. 빌드타임에 하는 도구와 런타임에 하는 도구가 다 있습니다. 대신 이건 최적화하는만큼 적용한 부분에 대해서 유연성은 떨어지겠죠.

2번은 데이터로더를 모듈러하게 구성하면 해결이 되고요

post loader
post summary loader -&gt; post loader
post detail loader -&gt; post loader

처럼 의존성을 걸어주면요. 로딩할 때 적당히 캐시를 잘 활용하고 적당히 의존하는 캐시 prime 처리를 잘 해주면 될겁니다.

두 분 모두 답변 감사합니다! 크으…:+1: join-monster 같은 라이브러리가 있었군요….

저런 종류의 라이브러리들이 대단히 많으니 더 찾아보시고 적합한거 선택하세용

compiler GraphQL to SQL 등등으로 검색하면 나올겁니다

좋은 키워드 주셔서 감사합니다! 위에 의존성 말씀하신 것도 참고해볼게요!

<https://relay.dev/graphql/connections.htm#sec-Edges|edges 스펙> 보면 `... must return a list type ...` 으로 되어있고 <https://relay.dev/graphql/connections.htm#sec-Node|node 스펙> 보면 `... Non-Null wrapper ...`  로 되어있어서

```edges: [Edge!]!```
```edge: {
  cursor: String!
  node: Node!
}```
요렇게 하는게 맞지 않나 싶긴 하네요~ (사실은 잘 모릅니다 ㅎㅎ)

릴레이 공식 문서 예시에는 `[Edge]` 와 `Node` 로 되어있긴 합니다 :joy:

그렇군요~

optional로 정의되어있는 명세를 required로 주고받아도 별다른 문제는 없을거라 예상하긴 하는데 한번 해보시고 저도 결과 공유주실 수 있나요?ㅎㅎ

넵, nullability 를 유지하는 이유는 에러처리 때문인데요.
<https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability>

적어도 edges의 non-empty/null 구분은 무의미하지 않나... 싶습니다.

원래 GraphQL 초기 스펙에 Non-nullable이 없었습니다 ㅎㅎ  (추후에 Nullable이 추가됨) 아마 Connection Spec도 그때 만들어져서 `[Edge]` 이지 않을까 싶네요

nodes: [Node!]! 를 추가해두는 것도 꽤 일반적이긴 합니다.

Non-null 로 하는것도 많이 하는거 같긴해요. 아무래도 백엔드마다 처리하는게 차이가 있을테니까 제일 넒은 사례로 다 nullable 처리해둔거지 싶어요

만약 특정 Edge나 Node 에서 에러가 나면 전체 목록이 invalidate 되는점?

그렇군요. 어차피 사내에서 사용하는 API라서, 프론트엔드 개발자분들의 취향에 따라 `[Edge!]!` 로 정해질 것도 같습니다 ㅎㅎ

생각하시는 스키마나 쿼리를 적어주시겠어요?

예를 들어서 가입된 사용자의 리스트를 얻고 싶다면 다음 쿼리를 쓸 수 있을 텐데 root field에서 connection, edge라는 네이밍이 어색하게 느껴집니다.
```query {
  usersConnection {
    edges {
      node {
        id
      }
      cursor
    }
    pageInfo {
      startCursor
      endCursor
    }
  }
}```
root field에서는 차라리 이런 네이밍이 더 자연스럽게 느껴집니다.
```query {
  usersWithCursor {
    users {
      id
    }
    cursor
  }
}```
오 예시 쿼리를 써보니 생각났는데요, 그래도 root field에서만 connection을 안 쓰는 건 안 좋은 것 같습니다. 그래서 질문을 다른 식으로 하자면 “root field에서 connection의 네이밍을 어떻게 하면 좋을까요?“가 되는 것 같습니다.

엇 처음 고민해보는 내용이네요 ㅋㅋ 저는

```query {
  users(first: 5) {
    edges {
      node {
        id
      }
    }
    pageInfo {
      startCursor
      endCursor
    }
  }
}```
이렇게 쓰는거 같아요 ㅎㅎ

&gt; cursor-based pagination을 구현하는 방식이라는 측면에서 시맨틱한 의미는 신경 쓰지 말고 그냥 connection 방식을 사용해도 될까요?
어차피 relay 쓰려면 `@connection` directive를 쓰긴해서 ㅎㅎ 이름을 바꾸거나 해서 시맨틱한 의미를 바꾼달지 하기는 힘들거같네요.

혹시 클라이언트는 뭐 쓰세요??

relay 써보려고 하고 있어요.

그러면 root field 말고 하위에 있는 필드에서도 Connection이라는 postfix를 안 붙이시나요? 이런 식으로요
```query {
  user {
    friendsConnection {
      friendsEdges {
        node {
          id
        }
      }
      pageInfo {
        startCursor
      }
    }
  }
}```
<https://www.apollographql.com/blog/graphql/explaining-graphql-connections/#73a6|apollo blog>에서 `${origin}${relationship}Connection` 이라는 네이밍 컨밴션을 소개시켜주었는데 의미를 이해하게 되어서 저는 이렇게 쓰려고 했었거든요

오오 맞아요 그게 좋긴하죠 ㅎㅎ 저는 connection 네이밍은 크게 의견 없습니다 ㅋㅋ

github api 참고해보니까 예시 들어주셨던 것처럼 필드 이름은 `users`와 같이 복수형을 쓰고 type 이름을 `UserConnection`이런 식으로 쓰는 것 같아요

users라는 이름의 필드가 리스트가 아닌 게 조금 마음에 걸려서 다음처럼 스키마와 쿼리를 짜보려고 합니다.
```type Query {
  userConnection: UserConnection
  user: User
}

type UserConnection {
  userEdges: [UserEdge]
  pageInfo: PageInfo
}

type UserEdge {
  node: User
  cursor: String
}

interface Node {
  id: ID!
}

type User implements Node {
  id: ID!
  friendConnection: UserFriendConnection
}

type UserFriendConnection {
  friendEdges: [UserFriendEdge]
  pageInfo: PageInfo
}

type UserFriendEdge {
  node: User
  cursor: String
}```
```query {
  userConnection {
    userEdges {
      node {
        id
      }
      cursor
    }
    pageInfo {
      startCursor
      endCursor
    }
  }
}```
```query {
  user {
    id
    friendConnection {
      friendEdges {
        node {
          id
        }
        cursor
      }
      pageInfo {
        startCursor
        endCursor
      }
    }
  }
}```
root field에 connection postfix가 어색했었는데 애플리케이션이 user라는 관계로 데이터를 가지고 있다고 생각하려구요. 그래프 구조로 생각한다면 아래 그림처럼 가상의 z축을 가정하는 약간의 정신승리를 해봤습니다.:sweat_smile:

`userEdges` 이렇게 해도 relay에서 `usePaginationFragment` 잘 돌아가는지 궁금하네요 ㅋㅋ 저는 항상 `edges` 필드를 썼었어요.

커넥션은 user 라는 데이터보단 User 라는 타입과 연관이 있습니다.

그래서 보통 복수형이 나오고, 백링크를 많이 쓰는거같아요

&gt; `userEdges` 이렇게 해도 relay에서 `usePaginationFragment` 잘 돌아가는지 궁금하네요 ㅋㅋ 저는 항상 `edges` 필드를 썼었어요.
요부분은 제가 아직 경험이 부족해서 전혀 생각을 못했습니다. 혹시 안된다면 잘 돌아가는 데에 맞추긴 해야겠네요

apollo 블로그에서는 말씀주신 대로 복수형을 써서 설명해주더라구요. 근데 github api는 단수형을 써서 저도 그거를 따라해봤어요ㅎㅎ

그나저나 이런 질문 너무 좋네요 ㅋㅋㅋ 덕분에 커뮤니티가 풍성해진거같아요~ 감사합니다

<https://twitter.com/KrComet/status/1398344970482851842>

<@UN4AJARCN> 스키마에선 기본 에러 타입을  interface로 구현하시진 않았나요?

ㅇㅎ notFound가 기본 interface를 구현하면 되겠네요 ㅎㅎㅎ

엥 제 기억엔 기본이 옵셔널이였는데

아 리졸버가 옵셔널인게 아니라

리졸버의 리턴타입을 바꾸고 싶다는거군요

제너레이터 옵션으로는 resolver fn 을 바꾸면 되고요

그 쪽 옵션 안바꿀거면 생성된 타입을 재귀적으로 변경하는 타입레벨 유틸리티를 짜면 됩니다

기본이 `(parent: TParent, args: TArgs, context: TContext, info: GraphQLResolveInfo) =&gt; Promise&lt;TResult&gt; | TResult` 인데

`(parent: TParent, args: TArgs, context: TContext, info: GraphQLResolveInfo) =&gt; Promise&lt;DeepPartial&lt;TResult&gt;&gt; | DeepPartial&lt;TResult&gt;` 이 되면 되는거죠

좋은 방법은 아니라 별로 추천하지 않습니다.

음 그럼 어떤 방법을 추천하시나요…?

아 제 말은 이 문제를 해결할 다른 방법이 있는지

실제 문제는 어떤건지 모릅니다 질문에 포함이 안되어있어서요

이미 수단이 정해져서 질문을 하셔서요

저건 그냥 타입스크립트 수준에서 하셔도 됩니다

사실 타입스크립트 수준에서 해결을 해야 그걸 옵션으로 타입 제너레이터에 넣을 수 있죠

근데 그 타입이라는게 나는 이걸 이렇게 쓸거야 하고 주장하는거고 컴파일러는 그걸 믿을 수 밖에 없는데요

아시다시피 DeepPartial 을 먹여버리면 사실 타입을 쓰는 장점을 거의 포기하게 됩니다

아 대충 SDL에 `type Foo { item: Item, value: String }` 같이 정의된 타입이 있다고 치면 전체 리졸버에서는 `{ itemId: String, value: String }` 을 리턴하고 `Foo`의 리졸버에 `item` 에 대한 리졸버를 추가해서 `parent.itemId` 를 읽어서 가져오게 하고 싶은 상황입니다

질문이 거의 DeepPartial 은 어떻게 구현하나요? 였는데 DeepPartial 구현은 찾아보면 많이 존재합니다. 타입스크립트 타입라이브러리들이 거의다 제공하고 있어서 그걸 쓰셔도 됩니다

GraphQL 리졸버는 실행맥락을 반영하기 때문에

resolver의 리턴 타입이 해당 오브젝트 타입을 반영할거라는건 너무 단순한 가정이고 사실 codegen 은 GraphQL 타입에 대한 정보밖에 가지고 있지 않기 때문에 어쩔 수 없는 부분이기도 한데요

사실 이 문제에 대한 답은 실행맥락을 알고있는 쪽에서 정해주는거 밖에 방법이 없습니다.

리졸버의 첫번째 인자는 항상 추상적이에요 언어가 그렇게 설계되었기 때문에

그 추상화 수준은 어플리케이션 주인장 밖에 모릅니다

이걸 표현하는 가장 적절한 옵션은요

<https://www.graphql-code-generator.com/plugins/typescript-resolvers#custom-context-type-2> 이겁니다

GraphQL Type 과 애플리케이션 맥락을 매핑할 수 있는 모델을 만들고 매퍼에 넘겨줘야해요

DDD 보셨으면 거기서 포트라고 부르는 것, 아님 다른 프레임워크에서 DTO라고 부르는 것과 비슷합니다

음 그러면 결국 개별 타입에 대한 정의는 따로 해주는 방향으로 사용을 해야 하나 보네요… 뭐 다른 방법이 있을 수가 없을 것 같긴 한데 ㅋㅋㅋㅋㅋ 암튼 감사합니다

물론 저런걸 일반화한 시도도 많이 있긴 합니다

<https://github.com/gajus/graphql-lazyloader>

아 이건 런타임이지 타입에 대한 해결책이 아니군요

타입 수준에서는 직접 추상화 하셔야할듯

그냥 partial 하고 뭉개셔도 되는데요 그럼 타입수준에서 안정성을 다 잃어버리니 대충하지 않는걸 추천드립니다

id 만 가지고 초기화 되는건 그럴 수 있지만

적어도 사용하는 쪽에서 필요한 데이터를 밸리데이션하는게 보장되는 방식으로 만들 수 있을거같습니다

이미 엔티티 프레임워크를 사용하시는 경우 그런걸 담당할 레이어가 이미 구현되어 있을 수 있고요

아님 데이터로더 같은거 스까서 대충 만들면 많이 씁니다

로더가 몇중으로 나오는지 같은 것도 실제 스키마에 따라 필요한 수준이 다르기 때문에 위 라이브러리 같은거 말고 일반화된건 좀 찾기 어렵습니다

일반화 하면 유연성이 떨어져서요...

그러게요 클래스 만들어서 게터 같은 걸 붙여야 하나 싶어지는

사실 데이터로더만 해도 어느정도 스케일까지는 충분하긴 해요

보통 찾으시는 물건은 테이블이 너무 거대해지거나 등등의 이유로 DB IOPS가 빡세지면 고려하게되는데

그마저도 앞에서 캐싱을 잘해주면 많이 미룰 수 있는지라

레이지 로딩을 고려하는 순간 프로그래밍 모델에 어렵거나 불편해지는 부분이 굉장히 많은데요

안할 수 있으면 안하는게 좋지 않나... 합니다

혹시 Postgraphile 쓰면 쿼리 옵티마이저에서 이런 거 다 처리해주려나요

그걸 정말 잘 만든(?) 사례가 뭐냐면 액티브레코드 라고 불리는 물건인데요

아 Postgraphile 은 GraphQL-to-SQL 에 가깝습니다

쿼리가 컴파일되서 나가기 때문에 그런걸 신경을 안씁니다

네 그니까 다 처리해주는게 맞긴 한데요. 여전히 유연성과의 트레이드오프입니다.

(스레드) <https://twitter.com/KrComet/status/1440300251571572745>

<https://productionreadygraphql.com/blog/2020-05-21-graphql-to-sql/>

애초에 이 솔루션의 이름에서 알 수 있듯이 백엔드를 단일 모놀리스 SQL로 전제하고 시작한다는 함정이 있습니다

유연성 트레이드오프라는 건 스키마가 DB 모델에 영향받는 부분을 말씀하시는 건가요?

GraphQL 자체가 해당 DB에 대한 액티브레코드가 되는겁니다.

이쯤에서 액티브 레코드에 대한 논평도 굉장히 읽을만합니다

<https://www.mehdi-khalili.com/orm-anti-patterns-part-1-active-record>

뭔가 많이 쏟아졌는데….찬찬히 읽어봐야겠군요

덕분에 제 트위터에 그럴싸한 말이 +1
<https://twitter.com/KrComet/status/1494920089157586945>

혹시 AppSync는 Serverless Framework 같은거로 쓰시고 계신가요??

<@UN0GLRW14> 넵 amplify로 사용하고 있습니다!

저도 appsync 를 쓰고있어서 그런데, 혹시 Comment 기반으로 쿼리하고 싶으시다는게 정확히 어떤 내용인지 알 수 있을까요??

이거 post 쿼리할때 comment id 를 조건으로 가져오고 싶으시다는거죠?
저도 이제 막 appsync 를 시작해서 잘은 모르지만 이거 dynamoDB resolver 에서 filter 줘야 할것 같아요.
<https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-dynamodb-resolvers.html>
이 링크 한번 참고 해보세요 :slightly_smiling_face:

루트 리졸버도 필드 리졸버에요 ㅎㅎ Query 타입의 필드 리졸버인거죠. 혹시 프레임워크 어떤거 사용하시나요?

<https://github.com/gajus/graphql-lazyloader> ?

<@UN0GLRW14> 아 그렇네요! 지금은 아폴로를 사용하고 있습니다. 단어를 잘못 사용했네요;; 쿼리를 처리할 때  제일 먼저 호출(탑 레벨)되는 리졸버에서 많은 필드를 처리하는것보다 더 잘게잘게 분리하자는 뜻이 였어요 ㅎㅎㅎ

<@UN4AJARCN> 오 감사합니다! 역시 이미 있군요 :grinning: 

&gt; 쿼리를 처리할 때 제일 먼저 호출(탑 레벨)되는 리졸버에서 많은 필드를 처리하는것보다 더 잘게잘게 분리하자는 뜻이 였어요
<@U01ERKWBZ7U> 당연하게도 그게 맞습니다 ㅎㅎ 최상위 Query Resolver에서 JOIN을 해서 내려준다던지 하면 엔티티간의 의존성이 짬뽕되어버려서 구조적으로 안 좋아요. 나중에 엔티티 단위로 Key-value 캐시를 바를때도 힘들구요.

특정 모델(테이블)이 너무 커져서 별도의 Remote Service(HTTP, gRPC 서버)로 분리한달지, 다른 DB(NoSQL, Memcached, Redis)로 옮긴달지 하는 경우에

• 최상위 쿼리 리졸버에서 JOIN한 경우
• 각 필드 리졸버에서 DataLoader로 가져온 경우
어디가 더 유연한지 떠올려보시면 좋을 것 같습니다~

혜성님이 올려주신 lazyloader도 좋네요 ㅋㅋ

더 나은 방향으로 가고 있는 것 같아 다행이네요 ㅎㅎ 감사합니다!

filters 같은 경우는, 지정하지 않으면 목록 쿼리에서 넘어가는 필터 인자들이 전부 connection id 를 생성하는데 사용되는데요, 필터 종류가 많아지면 조합이 기하급수적으로 늘어날 수 있기 때문에 이를 방지하고 명시적으로 필터를 관리하고 싶을때 씁니다.

Guided Tour 에 내용이 좀 있으니 참고해보시면 좋을 듯 합니다
<https://relay.dev/docs/guided-tour/list-data/updating-connections/#connection-identity-with-filters>

Apollo 나 URQL 에 있는 캐시 키 인자랑 역할이 동일합니다

2번 질문에 대한 답은.. Relay 용어집에 내용이 듬성듬성 있는데 이거 외에 디테일은 문서에서 확인하기 좀 어려우실 겁니다. 제 권장은 관련 테스트코드를 찾아보시는것이..

<https://relay.dev/docs/glossary/#preloadable-query-registry>

설명이나 코드에 따르면 Preloadable Concrete Request 객체를 생성하기 위한 지시자이고, 생성된 Preloadable Concrete Request 객체들은 중앙 레지스트리에 등록되어 관리되고, 이 레지스트리는 RN 에서 동적 로딩 관련 동작을 보장하기 위해 필요하다고 하네요

출력이 다른 이유는 뭐가 더 있을지 모르겠지만, 컴파일러 코드에서 preloadable 의 경우 relay runtime 의 Preloadable Concrete Request Registry 에 생성된 객체를 미리 등록하는 코드가 출력하는 코드를 볼 수 있습니다.

<https://github.com/facebook/relay/blob/764af24d78b4cfca95a82e82afae405efe0d3ad2/compiler/crates/relay-compiler/src/build_project/artifact_content.rs#L456>

음 왜 react query를 쓰려고 하시나요? 당연히 graphql client를 써야합니다. 자동화된 normalized cache가 graphql의 본질과 같은거라서요.

단점이라고 하면 graphql api 설계가 best practice에서 벗어나서 잘못갈 가능성이 높습니다 ㅠ 기술을 잘못 사용할테니 레거시를 높일거구요.

만약에 현규님이 기존에 relay를 사용해보셨거나 서버 개발자분이 relay server spec에 익숙하시거나. 팀 전체가 graph 기반으로 도메인을 표현하는데 익숙하시다면… 기술 자체로는 큰 단점은 없습니다.

그런 측면에서 Apollo Client 보다는 Relay를 추천드립니다

<@UN0GLRW14> 상세한 답변 감사합니다!! 기존 rest api 방식에 react query를 사용중인 상황에서 graphql을 도입하려고 하는 상황인데, 아직 팀 내에서 graphql 관련하여 익숙하신 분이 없어서 추가로 graphql을 위한 library를 도입해야하나 의문이 들어서 조사를 하고 있었습니다.

graphql api 설계에 대한 best practice와 relay에 대해 자세히 조사해보겠습니다 감사합니다.

번들사이즈 부담이 크긴한데요. 만약에 GraphQL “제대로” 해보기로 방향성을 정하셨다면, (저는 제대로가 아니면 안쓰시는게 낫다고 생각합니다) 기존 react-query와 relay 혼용해서 쓰면서 서서히 넘어가는게 좋다는 생각입니다!

<https://relay.dev|https://relay.dev>
<https://book.productionreadygraphql.com|https://book.productionreadygraphql.com>

혹시 구체적인 도움 필요하시면 DM 주셔요 ㅎㅎ

왜 GraphQL로 전환하려고 하시나요?

저희가 이번에 새로 제작하게 될 도메인에 대해서 설계를 했을 때 도메인 특성 상 스키마는 복잡하지 않은데 api를 많이 작성해야 하는 상황이라서 graphql을 도입해보면 이러한 부담을 줄일 수 있지 않을까 생각했습니다. 그리고 개인적으로 새로운 프로젝트에 도입할 수 있는 기회도 많지 않을 것 같아서요.

그런데 이렇게 도입하게 되면 기존에 사용하는 admin 사이트에서도 api를 추가로 작성해야 하는데 이미 사용하고 있는 react query로 대체할 수 있지 않을까 해서 생각했었습니다.

한마디로 새로운 도메인에 graphql을 도입하는 과정에서, 영향이 가는 다른 도메인에 graphql을 혼용하게 될 수 있다고 생각했습니다!

만약 사내에서만 쓰는 admin이라고 하시면, 저는 graphql + retool 권유드립니다 ㅎㅎ 저희 그렇게 쓰고있는데 참 좋아요.

<https://blog.cometkim.kr/posts/thinking-in-graphql-ko/|https://blog.cometkim.kr/posts/thinking-in-graphql-ko/>

요거 읽어보셔도 좋을거같습니다 ㅎㅎ

&gt; 그런데 이렇게 도입하게 되면 기존에 사용하는 admin 사이트에서도 api를 추가로 작성해야 하는데 이미 사용하고 있는 react query로 대체할 수 있지 않을까 해서 생각했었습니다.
만약에 admin이 고객에게 드러나는 핵심 제품이 아니라면 (프론트엔드 퀄리티를 안챙겨도 된다면) 혼용해서 쓰는것 타협할수있는 범위라고 생각합니다 ㅎㅎ

오오 정말 감사합니다! 

저도 사내에서만 쓰는 admin이라서 제안해주신 방법들 참고하겠습니다!

안그래도 graphql관련해서 좋은 문서들을 찾고 있었는데 열심히 공부하겠습니다 ㅎㅎ

&gt; <https://blog.cometkim.kr/posts/thinking-in-graphql-ko/>
공유해주신 글 읽어봤는데 정말 새로운 관점으로 보면서 graphql에 대해서 다시 생각하게 되는 것 같네요:+1:

넵 ㅎㅎ 제가 이것저것 쏟아냈는데... 혹시 궁금한게 있으시면 또 남겨주세요!

디렉티브 직접 처리하셔야할것 같은데요

쓰고는 있는데 이 문제 해결에 어떻게 도움이 될지는 감이 안 잡히네요….?

일단 directive 와 executable schema 부터 설명하겠습니다

디렉티브는 sdl 과 operation 에 붙일 수 있는데 아시다시피 그 자체로는 역할이 없고 사용하는 GraphQL 엔진에서 구문확장의 용도로 주로 사용합니다.

그래서 보통 makeExecutableSchema 같은거 돌리는 과정에서 사라지고

makeExecutableSchema 유틸은 해당 디렉티브를 만난 곳에서 스키마나 리졸버를 덮어 씌우는 식으로 구현되어있습니다

여기서 하고싶으신건 아마 graphql-codegen 으로 묶은 SDL 을 처리하고 싶으신걸텐데요

전에 맥락에서 유추해봤을 때 소스 스키마는 여러군데 있을것이고 이걸 graphql-codegen 으로 병합해서 하나의 SDL 파일을 얻으셨을 텐데 includeDirectives: true 옵션을 줘서 사용하신 디렉티브가 그대로 포함되어 있을겁니다

`@computed` 라는 디렉티브를 만들었는데 이걸 만나면 스키마를 nullable 로 바꾸는 처리를 하고 싶으신거잖아요

Apollo Server 같은거 쓰신다면 거기선 이미 makeExecutableSchema 를 써서 해당 동작을 구현하셨을테니 익숙하실텐데요

아닙니다 스키마는 원래 Nullability를 유지하어야 하고

리졸버가 Null을 반환하면 Cascade하게 깨지는 게 생각 중이던 방향이었는데

굉장히 이상한 사례군요 타입이 부정확했으면 좋겠다는게 요구사항이 맞나요

음 어떤 면에서 이상하다고 생각하시나요? 세이프티가 깨진다는 측면이신가요

API 를 반영하는 타입이 아니라면 애초에 생성할 필요가...

막상 GraphQL 응답은 Non nullable 인데 TypeScript 에서 Nullable 이라는게 이해가 안됩니다

GraphQL 응답에 대한 직접적인 타입을 원하시는게 아닌거같습니다

Lazy하게 데이터를 당기고 싶다는 맥락인데요

그럼 그냥 생성한 타입을 사용해서 접근자 유틸같은걸 만드시면 됩니다

graphql 타입정보 가지고 해킹할건 아닌거같고요

그냥 getter 만들어서 get하는 타이밍에 로딩을 하라는 말씀이시죠?

API 응답은 응답대로 놔두고 접근제어를 하라는 얘기엿습니다

non-null 을 Lazy&lt;T&gt; 로 바꾼다던지 그런건 아주 다른 관심사니까

graphql-codegen 은 클라이언트 생성기가 아니라 그냥 타입 코드만 뱉을 줄 알아요

클라이언트를 기대하시면 안됩니다. 클라이언트는 apollo-client 나 urql 같은게 클라이언트에요

아 넵 무슨 말씀이신지 대충 할 것 같습니다

그리고 이쪽엔 schema extension 은 안들어갑니다

Prisma와 리졸버 사이에 데이터 레이어를 하나 만들어주는 방식으로 진행해야겠네요

혹시 다루고 싶으신게 schema extension 이 아니라 operation extension 일수도 있겠다는 생각이 드는데