This message was deleted.
# 질문
s
This message was deleted.
t
schema가 서로 디펜던시가 있어서, 1개의 루트 스키마에 하위 필드들로 resolver chaining으로 연결된 상황이구요,
스키마 사이에 디펜던시가 있다는거랑 resolver chaining? 이 무슨 뜻인지 잘 모르겠어요 ㅎㅎ
watch, diff와 같은 함수를 실행하게 되어서 Next.js의 Node.js 서버에서 성능 이슈가 현저하게 떨어집니다.
혹시 flame chart로 확인하신걸까요?
i
스키마 사이에 디펜던시가 있다는거랑 resolver chaining? 이 무슨 뜻인지 잘 모르겠어요 ㅎㅎ
아 1번의 graphql api 호출로 해당 페이지내 모든 데이터를 하나의 루트 스키마 하위로 가져올수 있는 스키마 구성입니다.
혹시 flame chart로 확인하신걸까요?
넵!
t
루트 쿼리를 말씀하신거죠??
i
t
흠... 이게 그 getDataFromTree에서 발생하는 부하인가요?
i
어..
next.js진형에서는
getDataFromTree를
t
제 뇌피셜인데 데이터를 가져와서 캐시로 Normalize하는건 부하가 심하지 않을거같아서요
i
비추하는 상황이라서, 사용하고 있지 않씁니다
👍 1
t
이거 모르겠네요 ㅋㅋㅋㅋㅋ 혹시 Flamechart 공유해주실수있나요? 그 export가 될거에요
Apollo가 Apollo 했는지, 유저가 잘못했는지 파악이 좀 필요할거같아요
i
저거 차트를 줘도되는지는 보안검수 한번 여쭤볼게요!
t
엇 그렇군요 ㅋㅋㅋㅋ
혹시 쿼리가 어느정도 무거운지 궁금한데 프로덕션 나가있는 페이지 하나 던져주실수있나요?
i
아 저희가 아직 프로덕션으로는 배포가 안되어서요 ㅋㅋ 프로덕션 전에 성능 테스트중입니다 ㅠㅠ
api응답 크기는 16kb정도입니당
크면 40~50까지도 나옵니다
t
아하... 음 만약에 공유하시는게 힘드시면 재현가능한 경로가 필요할거같네요.
성능 이슈가 현저하게 떨어집니다.
저도 궁금하네요. 이거 크리티컬한건데요 ㅠ Apollo보다는 Relay가 이런 이슈 안 겪고 믿고쓰기 참 좋은데...
i
ㅠㅠ 얼마전에 makeVar도 메모리릭이슈도 있었고.. 애매하네요