GraphQL API Merge Request 체크리스트

GitLab GraphQL API는 상당한 복잡성을 가지고 있기 때문에 GraphQL 변경 사항을 포함한 Merge Request은 GraphQL에 익숙한 사람에 의해 검토되어야 합니다. @gitlab-org/graphql-experts 그룹이나 #f_graphql 채널(GitLab 팀 멤버만 이용 가능)을 통해 누군가를 M.R.에 핑할 수 있습니다.

GraphQL 쿼리는 다음 사항을 위해 검토되어야 합니다:

  • 파괴적인 변경 사항
  • 권한
  • 성능

검토 기준

이것은 철저한 디렉터리이 아닙니다.

샘플 쿼리를 포함한 설명

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

파괴적인 변경 사항 없음(특정 기간이 지난 후에만)

M.R.을 파괴적인 변경 사항을 확인하세요.

요소가 실험으로 표시된 경우, 폐기 기간 없이 즉시 파괴적인 변경 사항을 수행할 수 있습니다.

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

다중 버전 호환성

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

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

기술적 작성 검토

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

변경 로그

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

프레임워크 사용

GraphQL은 많은 부분들을 가진 프레임워크입니다. 프레임워크를 따르는 것이 중요합니다.

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

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

권한

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

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

성능

다음 사항을 확인하세요:

적절한 유형 사용

예를 들어:

  • 루비 TimeDateTime 객체에 대한 TimeType
  • id 필드에 대한 전역 ID

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

적절한 복잡성

쿼리 복잡성은 쿼리의 비용을 양적화하는 방법입니다. 쿼리 복잡성 제한은 스키마의 상수로 정의됩니다. 리졸버나 유형이 호출 비용이 많이 드는 경우, 해당 쿼리 복잡성이 그것을 반영하도록 보장해야 합니다.

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

테스트

  • 레졸버(단위) 스펙은 요철되며, 대신 요청(통합) 스펙을 사용하세요.
  • 프레임워크의 많은 측면이 resolve 메서드의 외부에 있으며, 요청 스펙은 그들이 올바르게 작동하는 유일한 방법입니다.
  • 모든 GraphQL 변경 M.R.은 이상적으로 API 스펙에 대한 변경을 반드시 포함해야 합니다.

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