GraphQL에서 "인덱스"목록과 "표시"세부 정보를 모델링하는 방법은 무엇입니까?

Question

내 데이터 모델에는 Folder 및 Messages의 두 가지 리소스가 있습니다. 각 메시지는 폴더에 속합니다. 때로는 각 폴더의 일부 필드를 포함하여 폴더 목록을 가져 오려고합니다. 때로는 특정 폴더의 세부 정보 (해당 폴더에 대한 일부 필드 및 메시지 포함)를 가져 오려고합니다.

Rails/RESTful 시스템에서는 Folder 리소스에있는 index 및 show 작업에 해당합니다. 후자는 원하는 폴더를 지정하는 id 매개 변수를 수신합니다. 이 스키마는 "관용적 인"GraphQL에서 어떤 모습일까요?

한 가지 방법은 각 작업에 대해 하나 개의 필드가 될 수 있습니다

type Query { 
    folders: [Folder] 
    folder(id: String!): Folder 
} 

지저분한 보인다는 힘들어 클라이언트가 인트로 스키마를 이해할 수 있습니다 여기에 몇 가지 중복있다.

아마 중복이 널 (NULL) 인수를 제거 할 수 있습니다 : id이 전달

type Query { 
    folder(id: String): [Folder] 
} 

경우, 그냥 Folder의 세부 사항은 반환됩니다 (한 항목의 배열 등). id이 nil 인 경우 모든 폴더의 세부 정보가 표시됩니다. 이 오버로드는 숨겨진 복잡성을 추가하는 것으로 보입니다.

어떤 접근 방식이 "우수 사례"입니까? 이 상황을 모델링하는 더 좋은 방법이 있습니까?

Answer 1

두 번째 방법을 사용합니다. 이 방법으로 나중에 같은 끝점에 인수를 더 추가 할 수 있습니다. 어쩌면 폴더에 경로가 있거나 생성 날짜를 필터링하고 싶을 수도 있습니다.

Answer 2

TLDR : 필드 값이 싸고 사용하십시오.

첫 번째 방법을 제안합니다. 같은 방식으로 REST API는 다양한 동작을 트리거하는 플래그로 절망적으로 혼란을 겪을 수 있으므로 다양한 인수가있는 필드를 사용할 수 있습니다.

이 경우 type Query { folders: [Folder!]! folder(id: String!): Folder }

, 당신은 항상 다시 folders에 대한 목록의 일종을 얻을 것이다, 그것은 포함되지 않습니다 : 두 개의 서로 다른 필드를함으로써, 당신은 또한 타입 시스템은 강력한 클라이언트 보증을 제공하도록 할 수 있습니다 임의 null s. 공허함은 빈 목록에 불과합니다. API는 자체적으로 문서화합니다. 옵션 인수가 점점 더 많은 것을 하나의 필드로 매쉬하려고 시도하는 경우에는 그렇지 않을 수도 있습니다.

folders의 페이지 번호를 매기려면 해당 끝점에 대한 페이지 매김 관련 인수가 필요하며 connection pattern의 중간 구조가 필요할 수도 있습니다.