쿼리 복잡도 분석 #13
쿼리 복잡도 분석 #13
Conversation
| @@ -76,7 +84,7 @@ | |||
| {:keys [timeout-ms timeout-error] | |||
| :or {timeout-ms 0 | |||
| timeout-error {:message "Query execution timed out."}}} options | |||
| execution-result (execute-parsed-query-async parsed-query variables context) | |||
| execution-result (execute-parsed-query-async parsed-query variables context options) | |||
There was a problem hiding this comment.
현재는 여기서 options에 :max-complexity 라는 key에 value를 넣어서 최대 리소스를 제한하는 것을 고려하였는데요.
system.edn 의 config 에 max-complexity를 하나 정의하여 context로 부터 가져와도 될 것 같다고 생각하는데 고민이긴 합니다.
There was a problem hiding this comment.
저희 백엔드 코드에서 build-lacinia-options할 때 현재 환경이 dev / staging인 경우에만 :max-complexity 값을 하드코딩해서 넘겨도 충분할 것 같습니다(ex: :max-complexity 1000000)
굳이 system.edn에는 추가 안 해도 될 것 같슴다
https://github.com/green-labs/farmmorning-backend/blob/68978493665d1027f45c4a64100a0855d5cb7781/bases/core-api/src/farmmorning/core_api/graphql/handler.clj#L97
다른 lacinia 옵션값들도 그냥 하드코딩하고 있음
There was a problem hiding this comment.
근데 지금 바로 반영된다면, 앱 코드들에 first: 9999 이런 잔재 때문에 프론트 개발자분들이 무조건 에러 응답들을 받아보실 텐데요..
우리 백엔드 미들웨어에서 라시니아 내부에서 뱉는 max-complexity 관련 에러는 로깅이나 슬랙만 보내고 by pass 한다던지의 의사결정만 될 듯 합니다!
There was a problem hiding this comment.
한 10만 정도로 설정해두고,
error에 code 하나 심어서 해당 code가 에러에 잡히면 근재님께서 제안해준 것 처럼 로깅이나 슬랙만 보내고 by pass하는게 좋을거같네요!
| @@ -0,0 +1,60 @@ | |||
| (ns com.walmartlabs.lacinia.complexity-analysis | |||
| (:require [clojure.core.match :refer [match]])) | |||
There was a problem hiding this comment.
라시니아에는 core.match 의존성이 아마 없을겁니다.
라이브러리인 만큼 의존성 추가 없는 쪽으로 구현하면 좋을 것 같습니다.
There was a problem hiding this comment.
넵! 로컬에서 팜모닝 서버 띄울때 에러가 발생하지 않길래 의존성이 있겠거니 했었는데 빼는쪽으로 수정해두겠습니다!
| (defn complexity-analysis | ||
| [query {:keys [max-complexity] :as _options}] | ||
| (let [{:keys [fragments selections]} query | ||
| pq (mapcat #(parse-query % fragments) selections) | ||
| complexity (count-nodes pq)] | ||
| (when (and max-complexity (> complexity max-complexity)) | ||
| {:message (format "Over max complexity! Current number of resources to be queried: %s" complexity)}))) |
There was a problem hiding this comment.
pq, complexity 는 max-complexity 옵션이 있을 때에만 계산이 되어야 하죠?
when 절의 and 를 둘로 쪼개야 하겠네요.
src/com/walmartlabs/lacinia.clj
Outdated
| :let [complexity-error (complexity-analysis/complexity-analysis prepared options)] | ||
|
|
||
| (some? complexity-error) | ||
| (resolve/resolve-as {:errors complexity-error}) |
There was a problem hiding this comment.
complexity-analysis 도 validator 중 하나로 설정할 수 있다면 좋겠는데...
이건 나중에 메인테이너가 어떻게 생각하는지 들어봅시다 ㅎㅎ
|
기존 팜모닝 코드 내에 존재하던 resource_limitation을 라시니아 내부로 이동시킵니다.
다른 언어로 작성된 라이브러리나 프레임워크들을 참고하였는데 (elixir - absinthe, ruby - graphql_ruby, haskell - hasura),
query validation -> (쿼리 복잡도 분석) -> execute 의 형태를 따라가고 있어 저희도 그와 같은 방식을 채택하여 작업하였습니다.
기존 팜모닝에서 작업했던 PR 에서는 단순히 request로 받은 쿼리를 분석하였다면, 이번에는 저희 schema와 쿼리를 먼저 합친 후 분석을 하도록 수정하였습니다.
그에 따라 schema에서 default로 정의된 값들을 쿼리 복잡도 분석에 사용하여 조금 더 정확한 분석결과를 얻을 수 있게되었습니다.