This message was deleted.
# 질문
s
This message was deleted.
t
굳이 더 적은 필드를 가져올때의 쿼리 리졸버를 나누시려는 이유가 뭘까요??
SQL에서 select를 덜하기 위해서인가요?
d
네네 그렇습니다. 단편적인 예로 말씀을 드렸지만, 조금 더 복잡한 조인이 많을 경우에 불필요하게 리소스가 낭비된다고 생각했어요.
h
1. resolver 에선 최대한 lazy loading 하고 엔티티 프레임워크에서 알아서 잘 해결한다. 2. 데이터 로더에서 해결한다. 3. 런타임 정보(GraphQLInfo)를 분석해서 사례를 동적으로 나눈다 4. 미리 등록된 쿼리별로 SQL 을 컴파일 하는 식으로 사례를 정적으로 나눈다 스키마를 바꾸지 않고는 이런 접근법들이 있겠습니다.
👀 1
d
나약한 소리지만… 답변 주신 걸 다 이해하진 못했네요ㅠㅠ 1, 4번은 클라이언트와 서버 간의 암묵적인? 약속인건가요? 클라에서는 id, title, imageUrl만 패치할거니깐 그것만 내려줘! 이렇게?
h
다 서버에서의 해결책입니다
1번은 이미 서버에 있을수 있는 Data access layer 의 기능을 더 잘 활용하자... 이런거구요
3, 4번은 https://github.com/join-monster/join-monster 같은걸 말합니다. 빌드타임에 하는 도구와 런타임에 하는 도구가 다 있습니다. 대신 이건 최적화하는만큼 적용한 부분에 대해서 유연성은 떨어지겠죠.
👀 1
2번은 데이터로더를 모듈러하게 구성하면 해결이 되고요
post loader post summary loader -> post loader post detail loader -> post loader 처럼 의존성을 걸어주면요. 로딩할 때 적당히 캐시를 잘 활용하고 적당히 의존하는 캐시 prime 처리를 잘 해주면 될겁니다.
👀 1
d
두 분 모두 답변 감사합니다! 크으…👍 join-monster 같은 라이브러리가 있었군요….
h
저런 종류의 라이브러리들이 대단히 많으니 더 찾아보시고 적합한거 선택하세용
compiler GraphQL to SQL 등등으로 검색하면 나올겁니다
👍 1
d
좋은 키워드 주셔서 감사합니다! 위에 의존성 말씀하신 것도 참고해볼게요!
t
DataLoader 추천드립니다 ㅎㅎ
🙏 1