Validation
타입 시스템을 사용함으로써 GraphQL 쿼리가 유효한지 아닌지 미리 알 수 있다. 이는 서버와 클라이언트가 유효하지 않은 쿼리가 생성되었을 때 개발자에게 런타임 체크에 의존하지 않고 이를 효과적으로 알려줄 수 있게끔 한다.
우리의 스타워즈 예제에서 보면 파일 starWarsValidation-test.js 은 유효하지 않은 많은 쿼리를 포함하고 있으며 구현의 유효성 검사기를 실행할 수 있는 테스트 파일이다.
먼저 유효한 쿼리를 보자. 이것은 nested 쿼리이며, 이전 섹션에서 나온 예시와 비슷하지만 중복된 필드들은 fragment로 빼내었다.
이 쿼리는 유효하다. 이제 무효한 쿼리를 살펴보자.
fragment 는 자신을 참조하거나 싸이클을 생성할 수 없는데, 왜냐하면 이건 무한한 결과를 초래하기 때문이다. 아래 쿼리는 위의 쿼리와 같지만 3단계의 nesting 을 없앤 쿼리이다.
필드에 쿼리를 할 때, 주어진 타입에 있는 필드를 요청해야 한다. hero 필드는 Character 타입을 리턴하기 때문에, Character 타입에 있는 필드를 쿼리해야 한다. 이 타입은 favoriteSpaceship 이라는 필드가 없기 때문에 이 요청은 무효하다.
스칼라나 enum 이외의 것을 리턴하는 필드를 요청하는 경우, 우리는 반드시 어떤 데이터를 돌려받고 싶은지 명시해야 한다. hero 는 Character 타입을 리턴하는데, 지금까지는 name 과 appearsIn 같은 필드를 요청하였다. 만약 이를 생략한다면, 쿼리는 유효하지 않다.
같은 맥락에서, 만약에 필드가 스칼라라면 여기에 추가적인 필드를 요청하는건 말이 안된다. 그리고 이렇게 한다면 유효하지 않은 필드가 된다.
앞서, 쿼리는 해당 타입의 필드만 쿼리할 수 있다고 하였다. Character 타입을 리턴하는 hero 에 쿼리를 할 때, 우리는 오직 Character 에 존재하는 필드에 대해서만 요청할 수 있다. 그렇다면 R2-D2 primaryFunction 을 요청 하고 싶다면 어떻게 해야 할까?
위의 쿼리는 유효하지 않은데 primaryFunction 은 Character 의 필드가 아니기 때문이다. 우리는 만약 Character 가 드로이드 일 경우 primaryFunction 을 가져오도록 표시할 수 있는 방법을 원한다. 우리는 이때 fragments 를 사용할 수 있다고 앞서 설명하였다. Droid 에 fragment 를 설정한 것을 포함하므로써 우리는 primaryFunction 이 정의된 곳에서만 요청을 하도록 확실하게 할 수 있다.
위의 쿼리는 유효하나 너무 길다. named fragments 는 여러번 사용될 때 유용하나, 우리는 위에서 한번만 사용하였다. 이럴 때에는 named fragments 를 쓰는 대신 inline fragment 를 쓸 수 있다. 이러한 방법으로 따로 fragment 에 이름을 정하지 않고 원하는 타입에 쿼리를 할 수 있도록 할 수 있다.
이 것은 유효성 검사의 일부분에 불과하다. GraphQL 쿼리를 더욱 더 의미있도록 하기 위해 많은 유효성 검사 룰이 있다. GraphQL.js 에 있는 validation 에서 GraphQL 의 유효성검사에 대한 코드를 볼 수 있다.
* 해당 글은 번역기 돌리다가 크롬 번역기 말도 안되는 해석에 지친 본인이 나중에 참고할 의도로 대충대충 발로 해석한 것이니 참고용으로만 사용하시길 바랍니다.
* 출처: https://graphql.github.io/learn/validation/
'배움의 즐거움 > 프로그래밍' 카테고리의 다른 글
| (6) GraphQL - 인트로스펙션 (0) | 2018.12.31 |
|---|---|
| (5) GraphQL - 실행 (0) | 2018.12.31 |
| (3) GraphQL - 스키마와 타입 (0) | 2018.12.31 |
| (2) GraphQL - 쿼리와 뮤테이션 (1) | 2018.12.31 |
| (1) GraphQL - 소개 (0) | 2018.12.31 |
