This message was deleted.

맥락이 너무 짧네요. 쿼리 컴파일 하는 시간 안줄이면 일반적으로 매우 느린게 맞긴 합니다

@Hyeseong Kim 친절한 답변 감사드립니다!! 제가 아직 학생이라 깊은부분까지 많이 이해를 못한거 같아 너무 허접한 질문을 드린 것 같네요 ㅠㅠ 혹시 4번이 가장 크다는 것은 제가 생각했을 때 AST 트리 형태로 파싱과정을 거친 후 최상단부터 너비우선 탐색을 통해 해당하는 필드의 resolver함수를 매핑하여 실행시키게 되는데 이 과정에서 resolver함수의 결과 값을 기다리고 그 후에 다른 필드의 resolver 함수를 실행하는 형태로 진행되서 느리다고 생각을 하였는데 맞을까요??

AST까지 나오면 탐색하는게 그리 크지는 않고요. AST 뽑으려고 구문분석하는게 더 크죠

@Hyeseong Kim 아하 AST를 만들기 위해 구문분석하는 과정에서 지연이 많이 발생하는 거군요.. 그럼 트리가 만들어진 후 resolver함수를 매핑시키면서 데이터를 가져오고 처리하는 과정에서는 그렇게 큰 지연이 발생하지는 않는 것인가요!?

넹 질문은 아무때나 채널에 남겨주세요

@Hyeseong Kim 감사합니다!! 제가 학습하면서 알게된 내용 중 클라이언트에서 요청하는 쿼리가 커졌을 경우 성능에 문제가 발생할 수 있기 때문에 쿼리의 maxDepth를 지정하여 요청을 제한하는 방식과 쓰로틀링 방식을 이용하여 지속적으로 요청하는 것을 제한하는 방식으로 해결한다는 것을 보았습니다. 쓰로틀링 방식으로는 1. 서버에서 쿼리를 처리할 수 있는 시간을 측정하여 해당 시간동안은 하나의 요청만을 처리하도록 하는 방식 2. 복잡도 기반으로 쿼리를 쓰로틀링하는 방식 이렇게 두 가지가 있는 것으로 알고 있는데 복잡도는 스키마를 보고 정적으로 복잡도를 계산할 수 있기 때문에 더 괜찮다는 생각이 드는데,, 복잡도라는 것에 기준이 따로 있는 것인가요??

아... API가 공개면 뭐 그런것도 있죠

혹시 팩터라는게 어떤건지 조금 설명가능하실까요???

예시를 들면 이런거죠 https://docs.github.com/en/graphql/overview/resource-limitations

아하 자체적으로 기준을 정해놓고 계산을 하는군요!!! 감사합니다 많은 도움이 되었습니다!! 조금 더 학습해보겠습니다 ㅎㅎ