什麼是一些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文章由李拜倫有用。