Slackbot
12/12/2019, 5:04 AMTony Won
SinYooDong
12/12/2019, 5:53 AMMARU
12/12/2019, 1:28 PMGraphQLResolveInfo
를 파싱해서 client 가 요청한 subselection 을 알아내시려는 건가요?
예를 들면
myResolver: (_, _, _, info ) => {
const subselection = library(info)
// 이후 subselection 을 (편집 후 prisma에) 사용
}
이런 거라면
https://github.com/robrichard/graphql-fields
또는
https://github.com/Mikhus/graphql-fields-list
한번 살펴보시면 어떨까 합니다.MARU
12/12/2019, 1:32 PMposts
resolver에서 사용하면 중간과 같은 json 을 얻을 수 있고,
author
resolver에서 사용하면 우측과 같은 json 을 얻을 수 있습니다.MARU
12/12/2019, 1:48 PMGraphQLResolveInfo
가 문서화되지 않아서(오직 코드: 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. 또는 해당 정보가 필요한 특수한 경우
등에만 사용하는게 좋겠다고 생각하고 있었습니다.
개인적인 경험과 생각을 적다보니 길어지네요. 질문의 요지를 이해하고 도움을 드린 게 맞으면 좋겠습니다.SinYooDong
12/13/2019, 2:19 AM