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

Question

我正在开发一个非常重要的应用程序,我们正在考虑使用GraphQL.在处理模式的初始草案时,我变得有点瘫痪,试图建立随着产品的成熟而扩展的命名约定.我真的很感激任何不得不发展架构并遇到或成功避免死角或不一致的人的一些见解:

1. 在接口名称中保留名称"Interface"通常是有用/惯用的吗？例如,在大型应用程序中是优选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. 最好的做法是将全有或全无objects 声明为scalar或者type,两者之间的界线在哪里？想象一下Point通常表示为数组的类型[x,y]; 哪个更像是风骚？

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

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

提前致谢!

---

这个问题没有得到我想要的动力,所以我会在发现它们时开始发布有用的片段,这可能会演变成各种各样的答案.

在末尾使用Input命名输入类型是一种有用的约定,因为对于单个概念对象,您通常需要输入类型和输出类型略有不同.

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

Answer 1

我思考这些问题,希望这对你有所帮助.

1.我不认为在每个界面的末尾添加接口是惯用的.更改一个描述性名称要好得多.考虑GraphQL规范中与接口相关的示例.它们不会将Interface附加到任何类型.

2.只有存在多个相关值时,枚举才有用.当只有一个可能的值时,我没有看到包含类型是如何有用的.根据与Enums相关的GraphQL规范,枚举值也以所有大写和下划线命名.

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

诸如Date,Email和Url之类的值是标量类型的常见示例.它们提供语义价值,客户将知道这些字段的期望.

这是自定义标量的相关部分.这是一个例子.

4.你会发现此文章由李拜伦很有帮助.

Answer 2

我前段时间从Shopify找到了这个graphql API设计教程。我认为整个教程中没有明确的章节，但命名约定的最佳实践。