GraphQL 스키마 명명 베스트 프랙티스는 무엇입니까?

GraphQL 스키마 명명 베스트 프랙티스는 무엇입니까?

GraphQL을 검토하고 있는 간단한 어플리케이션 개발을 시작하고 있습니다.스키마의 초기 초안을 작성할 때 제품이 성숙함에 따라 확장되는 명명 규칙을 확립하는 데 다소 어려움을 겪었습니다.스키마를 키워서 부딪히거나 막다른 골목이나 불일치를 성공적으로 피한 경험이 있는 모든 분들의 의견을 들어주시면 감사하겠습니다.

1. 일반적으로 인터페이스라는 이름을 인터페이스 이름으로 유지하는 것이 유용한가, 아니면 자동적인가?예를 들어,Profile또는ProfileInterface큰 앱에서 선호되는가?

   interface ProfileInterface {
     # fields here...
   }
   
   type UserProfile implements ProfileInterface {
     # implemented fields here...
   }
   

2. 단일 숫자 값을 "정수"로 지정하는 것이 일반적인가요?

   enum GeoJSONFeatureTypeConstant {
     feature
   }
   
   interface GeoJSONFeatureInterface {
     id: ID
     type: GeoJSONFeatureTypeConstant!
     geometry: GeoJSONGeometryInterface!
     properties: GeoJSONProperties
   }
   

3. all-or-nothing을 선언하는 것이 베스트 프랙티스입니까?object로서scalar또는type, 그리고 둘 사이에 선을 긋는 곳은 어디입니까?상상해 보세요Point일반적으로 배열로 표시되는 유형[x,y]; 어떤 것이 더 관용적인가?

   scalar Point
   
   type Point {
     x: Float
     y: Float
   }
   

4. GraphQL의 명명 규칙 또는 유형 선언과 관련하여 경험 없이는 알기 어려운 기타 베스트 프랙티스.

잘 부탁드립니다!

---

이 질문은 제가 원하는 모멘텀을 얻지 못했기 때문에 도움이 되는 토막글을 발견하면 바로 올리도록 하겠습니다.

입력 타입의 이름을 끝에 입력으로 붙이는 것은 편리한 규칙입니다.이는 단일 개념 오브젝트에 대해 입력 타입과 출력 타입이 약간 다른 경우가 많기 때문입니다.

http://graphql.org/graphql-js/mutations-and-input-types/

저는 이 질문들에 대해 고민했고 이것이 당신에게 도움이 되기를 바랍니다.

1. 모든 인터페이스의 끝에 인터페이스를 추가하는 것이 관용적이라고 생각하지 않습니다.대신 설명적인 이름을 갖는 것이 훨씬 낫다.인터페이스에 관한 GraphQL 사양에 기재되어 있는 예를 검토해 주십시오.어떤 유형에도 인터페이스를 추가하지 않습니다.

2. Enum은 관련된 값이 여러 개일 경우에만 유리합니다.가능한 값이 하나밖에 없는 경우 유형을 포함하는 것이 어떻게 도움이 되는지 모르겠습니다.Enum 값은 Enum과 관련된 GraphQL 사양에 따라 모든 대문자 및 밑줄을 사용하여 이름이 지정됩니다.

3. 스칼라 타입을 실장하는 경우는, 필드의 유효성을 확인하는 것은, 유저에게 달려 있습니다.이 경우 점이 2-D 또는 3-D일 수 있으므로 점을 유형으로 제공하는 것이 가장 적합합니다.유형으로 정의하는 것이 보다 선언적입니다.

날짜, 이메일 및 URL과 같은 값은 스칼라 유형의 일반적인 예입니다.의미적 가치를 제공하므로 클라이언트는 이러한 필드에서 무엇을 기대할 수 있는지 알 수 있습니다.

커스텀 스칼라에 대한 관련 섹션은 다음과 같습니다.여기 예가 있습니다.

4. Lee Byron의 이 기사가 도움이 될 것입니다.

얼마 전 Shopify에서 이 graphql API 디자인 튜토리얼을 찾았습니다.명확한 장은 없지만 튜토리얼 전체에 퍼진 명명규칙에 관한 베스트 프랙티스는 있다고 생각합니다.

언급URL : https://stackoverflow.com/questions/40923977/what-are-some-graphql-schema-naming-best-practices