GitLab GraphQL API는 상당한 복잡성을 가지고 있으므로, GraphQL 변경 사항이 포함된 머지 리퀘스트는 반드시 GraphQL에 익숙한 사람이 리뷰해야 합니다. 머지 리퀘스트나 Slack의 #f_graphql 채널에서 @gitlab-org/graphql-experts 그룹을 핑(ping)할 수 있습니다 (GitLab 팀원 전용).

GraphQL 쿼리는 다음 사항에 대해 리뷰가 필요합니다:

• 브레이킹 체인지(breaking changes)

• 인가(authorization)

• 성능

리뷰 기준#

다음은 전체 목록이 아닙니다.

샘플 쿼리가 포함된 설명#

설명에 설정 지침과 함께 샘플 쿼리가 포함되어 있는지 확인하세요. 로컬 GDK 인스턴스에서 GraphiQL을 통해 쿼리를 직접 실행해 보세요.

브레이킹 체인지 없음 (전체 지원 중단 사이클 이후가 아닌 경우)#

머지 리퀘스트에 브레이킹 체인지가 있는지 확인하세요.

기능이 실험(experiment)으로 표시된 경우, 지원 중단 기간 없이 즉시 브레이킹 체인지를 적용할 수 있습니다.

자세한 내용은 지원 중단 및 제거 프로세스를 참고하세요.

멀티버전 호환성#

멀티버전 호환성이 보장되는지 확인하세요. 일반적으로 동일한 GraphQL 기능의 프론트엔드 코드와 백엔드 코드는 동일한 릴리스에 포함될 수 없습니다.

자세한 내용은 멀티버전 호환성을 참고하세요.

기술 문서 작성 리뷰#

생성된 API 문서에 대한 변경 사항은 기술 문서 작성자의 리뷰가 필요합니다.

변경 로그#

실험(experiment)으로 표시되지 않은 공개적인 변경 사항에는 변경 로그 항목이 필요합니다.

프레임워크 사용#

GraphQL은 많은 구성 요소가 있는 프레임워크입니다. 프레임워크를 올바르게 따르는 것이 중요합니다.

• 프레임워크 요소를 수동으로 호출하지 마세요. 예를 들어, 실행 중에 리졸버를 직접 인스턴스화하지 말고 프레임워크가 처리하도록 맡기세요.

• MyResolver.single과 같이 리졸버를 서브클래싱할 수 있습니다 (리졸버 파생 참고).

• 더 복잡한 인수 로직에는 ready? 메서드를 사용하세요 (resolver#ready의 올바른 사용법 참고).

• 더 복잡한 인수 유효성 검사에는 prepare 메서드를 사용하세요 (전처리(Preprocessing) 참고).

자세한 내용은 리졸버 가이드를 참고하세요.

인가(Authorization)#

적절한 인가가 적용되었는지, 그리고 authorize :some_ability가 스펙(spec)에서 테스트되는지 확인하세요.

자세한 내용은 인가 가이드를 참고하세요.

성능#

다음을 확인하세요:

• N+1 문제를 확인하고 가능한 경우 최적화를 사용하여 N+1을 제거했는지 확인하세요.

• 지연 로딩(laziness)을 적절하게 사용하세요.

적절한 타입 사용#

예를 들어:

• Ruby Time 및 DateTime 객체에는 TimeType을 사용하세요.

• id 필드에는 Global ID를 사용하세요.

자세한 내용은 타입을 참고하세요.

적절한 복잡도#

쿼리 복잡도는 쿼리가 얼마나 비용이 많이 드는지를 수치화하는 방법입니다. 쿼리 복잡도 제한은 스키마에서 상수로 정의됩니다. 리졸버나 타입의 호출 비용이 높은 경우, 쿼리 복잡도가 이를 반영하도록 해야 합니다.

자세한 내용은 최대 복잡도, 필드 복잡도 및 쿼리 제한을 참고하세요.

테스트#

• 리졸버(단위) 스펙은 요청(통합) 스펙으로 대체되어 지원 중단되었습니다.

• 프레임워크의 많은 측면이 resolve 메서드 외부에 있으며, 요청 스펙만이 이들이 올바르게 동작하는지 확인할 수 있는 유일한 방법입니다.

• 모든 GraphQL 변경 머지 리퀘스트에는 이상적으로 API 스펙 변경 사항이 포함되어야 합니다.

자세한 내용은 테스트 가이드를 참고하세요.