什么是一些GraphQL模式命名最佳实践？

Question

我正在开发一个我们正在考虑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. 是否申报全部或全无object S作为scalar或type最佳实践，并在两者之间绘制的线？想象一下Point类型，它通常会被表示为一个数组[x,y];哪个会更加习惯？

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

4. 任何其他与GraphQL中的命名约定或类型声明特别相关的最佳实践，如果没有经验，将很难知道这些最佳实践。

在此先感谢！

---

这个问题一直没有得到我所希望的势头，所以我要开始张贴，因为我觉得他们有用的片段，这可能演变成各种各样的答案。

命名输入类型与在端输入是一个有用的惯例， 因为你通常希望两者的输入类型和输出类型 是针对单个概念对象略有不同。

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

Answer 1

我思索这些同样的问题，我希望这将有助于你。

1.我不认为在每个接口的末尾添加Interface都是惯用的。改为描述性名称会更好。考虑与接口有关的GraphQL Specification中提供的示例。它们不会将Interface添加到任何类型。

2.枚举仅在存在多个相关值时才有优势。当只有一个可能的值时，我不明白包含类型是有帮助的。枚举值也用与Enums相关的GraphQL Specification的全部大写和下划线命名。

3.如果您决定实施标量类型，则由您来验证该字段。在这个特定的情况下，将Point作为一个类型是最有意义的，因为Point可以是2-D或3-D。将它定义为一种类型更具说明性。

Date，Email和Url等值是标量类型的常见示例。它们提供语义价值，客户将知道从这些领域期望什么。

下面是定制标量的相关section。 这是example。

4.你会发现this文章由李拜伦有用。