typescript에서 다른 GraphQL 구문의 장단점

Question

Graphql에 대한 여러 자습서를 살펴 보았는데 모두 다르게 작성되었습니다. 나는 그들 모두에게 찬반 양론이 무엇인지 궁금해했다. 또한 형식, 쿼리 등을 다른 파일로 모듈화하는 방법은 무엇입니까? 내가 본 첫 번째 방법은 문자열을 사용하여 GraphQL 스키마를 설명하고이 스키마를 내 보낸 다음 스키마 파일로 가져 오는 것입니다. 이것은 다음과 같습니다 :

const typeDefs = ` 
type Query { 
    testString: String 
} 
`; 

그런 다음 express-graphql 패키지를 사용하고 스키마를 설명하는 객체를 사용하는 다음 방법이 있습니다. 이것은 다음과 같습니다 :

const todoType = new GraphQLObjectType({ 
    name: 'todo', 
    description: 'todo item', 
    fields:() => ({ 
    itemId: { 
     type: (GraphQLInt), 
     description: 'The id of the todo.', 
    }, 
    item: { 
     type: GraphQLString, 
     description: 'The name of the todo.', 
    }, 
    completed: { 
     type: GraphQLBoolean, 
     description: 'Completed todo? ' 
    } 
    }) 
}); 

다른 방법은 graphql 파일을 사용하는 것입니다.

개인적인 취향입니까 아니면 다른 것을 사용하는 것의 실제 이점이 있습니까?

필자가 언급 한 첫 번째 구문은 강조 표시가 부족할 수 있지만 실제 graphql 구문과 가장 유사합니다. 필자가 선호하는 방법은 graphql 파일을 사용하는 것입니다. 그러나 문제는 그것을 모두 모듈화하는 방법입니다. 어떻게 여러 개의 .graphql 파일을 병합하고 단일 스키마 내에서 사용합니까?

Answer 1

스키마 파일 또는 문자열 내부에서 쿼리를 정의하면 GraphQL 인터페이스를 신속하게 프로토 타입 작성할 수 있습니다. 이것은 시작하고 일부 확인자를 구현하는 것은 매우 좋습니다. 스키마가 커지면 스키마 정의도 엄청나게 커질 것입니다. 우리는 몇가지 타입을 가지고 있지만 스키마 파일은 1000 loc 이상입니다. 따라서 JavaScript에서 유형을 정의하고 정의 내에 리졸버를 작성합니다. 대부분의 리졸버는 매우 간단하며 실제 타입 결정 논리를 포함하는 데이터 로더를 사용합니다. new tool by GraphCool은 스키마 정의에서 가져 오기를 허용합니다. 이런 종류의 위의 내 포인트를 패배시키고 다른 동안 스키마 언어를 사용하여 확장 할 수 있습니다.

Btw : 사용 가능한 GraphQL 스키마 정의에 대한 구문 강조 표시가 있습니다. 아톰의 경우 language-babel