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. 将全有或全无

   object

   声明为

   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. 我不认为在每个接口末尾附加 Interface 是惯用的。最好有一个描述性的名称。考虑GraphQL 规范中提供的与接口相关的示例。他们不会将 Interface 附加到任何类型。

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

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

日期、电子邮件和网址等值是标量类型的常见示例。它们提供语义价值，客户将知道对这些字段的期望。

这是自定义标量的相关部分。 这是一个示例。

4. 您会发现李·拜伦（Lee Byron）的这篇文章很有帮助。

Answer 2

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