안녕하세요.

GraphQL

+ `relay`를 사용하고 있습니다. 백엔드에서는

nestJS

+

typeorm

기준으로 resolver는 이렇게 생겨먹었습니다.

// 목록
@Query(() => [Post])
findAll() {
   return ...
}

// 상세
@Query(() => Post)
findOne() {
   return ...
}

그리고 클라이언트에서는 이런 식으로 데이터를 사용하고 있습니다.

# 게시물 목록 아이템
fragment postItemFragment on Post {
   id
   title
   imageUrl
}
# 게시물 상세
fragment postDetailFragment on Post {
   id
   title
   imageUrl
   ...
}

일반적으로 목록 아이템의 경우 필요한 데이터가 상세 컴포넌트보다 훨씬 적습니다. Post의 모든 프로퍼티를 쿼리하더라도 목록 아이템에서는 3개 밖에 쓰지 않습니다. 이러한 경우에 객체 스키마를 어떤 식으로 구성하시는지 궁금합니다. 여러 가지로 시도해보고 있는데, 의견 주시면 너무 좋을 것 같아요!

@ObjectType
export class PostListItem {
  id
  title
  imageUrl
}
@ObjectType
export class PostDetail {
  id
  title
  imageUrl
  ...
}

# 이렇게 변경
@Query(() => [PostListItem])
findAll() {
   return ...
}
# 이렇게 변경
@Query(() => PostDetail)
findOne() {
   return ...
}

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

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

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

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

다 서버에서의 해결책입니다

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

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

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

DataLoader 추천드립니다 ㅎㅎ