This message was deleted.
# 질문
s
This message was deleted.
t
흠... 보통 저는 prisma-nexus를 써서요 ㅋㅋㅋ 원하는 답을 얻으실수있을지 걱정이네요 ㅠ 나중에 공유해주세요~~ ㅎㅎ
s
Nexus를 지금 검토해봐야겠네요ㅋㅋ 넣는다 넣는다... 하기만했는데ㅋㅋ
m
말씀하시는게
GraphQLResolveInfo
를 파싱해서 client 가 요청한 subselection 을 알아내시려는 건가요? 예를 들면
Copy code
myResolver: (_, _, _, info ) => {
    const subselection = library(info)
    // 이후 subselection 을 (편집 후 prisma에) 사용
  }
이런 거라면 https://github.com/robrichard/graphql-fields 또는 https://github.com/Mikhus/graphql-fields-list 한번 살펴보시면 어떨까 합니다.
robrichard/graphql-fields 의 예를 들면, 좌측이 query 라고 가정할 때,
posts
resolver에서 사용하면 중간과 같은 json 을 얻을 수 있고,
author
resolver에서 사용하면 우측과 같은 json 을 얻을 수 있습니다.
여담으로, 저는 개인적으로 처음 이걸 알아보게 된 계기가 이전에 @ojy6042 님께서도 이 채널에 질문하신 "필요한 것만 dynamic 하게 database query 를 요청" 하기 위함이었습니다.
GraphQLResolveInfo
가 문서화되지 않아서(오직 코드: https://github.com/graphql/graphql-js/blob/c82ff68f52722c20f10da69c9e50a030a1f218ae/src/type/definition.js#L489-L500) 디버깅으로 구조를 분류했고, 이후 라이브러리를 찾았습니다. 문제는 1. (field blacklisting, mapping 등으로) 매번 resolver 마다 작업하는 것이 번거롭고(특히 스키마 변경이 있을 때), 2. dataloader 의 key 에도 field 정보를 포함시켜야 해서, 같은 데이터(RDB로 치면 같은 row)라도 사실상 key 가 겹치는 일이 적어 cache의 효용도 적어진다. (dataloader 작성이 좀 더 번거로워지는 것도 포함입니다.) 는 것입니다. 그래서 1. field 의 수가 많거나 큰 타입(긴 TEXT 등)의 field 가 있는 경우, 2. schema type과 datamodel의 불일치를 어떤 이유던 resolver 레벨에서 해결하는데 필요한 경우, 3. 또는 해당 정보가 필요한 특수한 경우 등에만 사용하는게 좋겠다고 생각하고 있었습니다. 개인적인 경험과 생각을 적다보니 길어지네요. 질문의 요지를 이해하고 도움을 드린 게 맞으면 좋겠습니다.
👍 3
s
@MARU 저번에도 그렇고 계속 도움을 받네요 ㅋㅋㅋ field관련 모듈을 싹다 찾아서 확인했는데 딱 입맛에 맞는게 없더라구요. 다시 prisma에 사용하기 위해 gql형식으로 주는게 없나 했는데... 없기에 만들 생각을 하다가 너무 비효율적일것같고... GraphQLResolveInfo를 가공을 해야되는 조건이 필요한 부분은 아에 다른 query로 만들어서 요청하는걸로 자체적으로 합의봤습니다 ㅋㅋ
🙂 1