GraphQL API 병합 요청 체크리스트

GitLab GraphQL API는 상당한 복잡성을 가지고 있어서 GraphQL 변경 사항을 포함하는 병합 요청은 GraphQL에 익숙한 사람에 의해 검토되어야 합니다. 병합 요청에서는 GraphQL 변경 사항을 포함하는 경우 @gitlab-org/graphql-experts 그룹에서 누군가를 멘션하거나 Slack의 #f_graphql 채널(GitLab 팀 멤버만 이용 가능)을 이용할 수 있습니다.

GraphQL 쿼리는 다음을 검토해야 합니다:

  • 중단되는 변경 사항
  • 권한
  • 성능

검토 기준

이 목록은 전부가 아닙니다.

설명과 샘플 쿼리

설명에 설정 지침이 포함된 샘플 쿼리를 확인하세요. 로컬 GDK 인스턴스의 GraphiQL에서 쿼리를 실행해 보세요.

중단되는 변경 사항이 없음(완전한 폐기 주기 이후가 아닌 경우)

MR을 중단되는 변경 사항을 확인하세요.

기능이 실험으로 표시되어 있는 경우, 폐기 주기 없이 즉시 중단된 변경 사항을 만들 수 있습니다.

자세한 정보는 폐기 및 제거 프로세스를 참조하세요.

다중 버전 호환성

다중 버전 호환성이 보장되도록 확인하세요. 이는 일반적으로 동일한 GraphQL 기능을 위한 프론트엔드 및 백엔드 코드가 동일한 릴리스에 전달되지 않아야 함을 의미합니다.

자세한 내용은 다중 버전 호환성을 참조하세요.

기술 문서 검토

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

변경 로그

실험으로 표시되어 있지 않은 공개 변경 사항에는 변경 로그 항목이 필요합니다.

프레임워크 사용

GraphQL은 많은 구성 요소를 가진 프레임워크입니다. 프레임워크를 준수하는 것이 중요합니다.

  • 수동으로 프레임워크 부분을 호출하지 마십시오. 예를 들어 실행 중에 리졸버를 인스턴스화하지 마시고 프레임워크가 그 역할을 하도록 합니다.
  • MyResolver.single과 같이 리졸버를 서브클래싱할 수 있습니다(자세한 내용은 리졸버 파생 참조).
  • 보다 복잡한 인수 논리에 대해 ready? 메서드를 사용합니다(자세한 내용은 리졸버#ready의 올바른 사용 참조).
  • 더 복잡한 인수 유효성 검사를 위해 prepare 메서드를 사용합니다(자세한 내용은 Preprocessing 참조).

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

권한

적절한 권한이 따르도록 확인하고 스펙에서 authorize :some_ability가 테스트되었는지 확인하세요.

자세한 내용은 권한 가이드를 참조하세요.

성능

다음을 확인하세요:

적절한 유형 사용

예를 들어:

  • Ruby TimeDateTime 객체에 대한 TimeType 사용
  • id 필드에 대한 Global ID 사용

자세한 내용은 유형을 참조하세요.

적절한 복잡성

쿼리 복잡성은 쿼리가 얼마나 비용이 드는지를 양적으로 나타내는 방법입니다. 쿼리 복잡성 제한은 스키마의 상수로 정의됩니다. 리졸버나 타입이 호출하기 어려운 경우 해당 쿼리 복잡성이 그것을 반영해야 합니다.

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

테스트

  • 리졸버(단위) 스펙은 요청(통합) 스펙을 선호하며, 이제는 사용되지 않습니다.
  • 우리 프레임워크의 많은 측면은 resolve 메서드 외부에 있으며, 요청 스펙은 그들이 올바르게 작동하는 유일한 방법입니다.
  • 모든 GraphQL 변경 MR에는 이상적으로 API 스펙의 변경이 있어야 합니다.

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