最好的（GraphQl）API是您編寫的API

作為前端開發人員，我感謝GraphQl優雅的數據曝光。這就像一個可自定義的菜單，讓我精確地請求UI組件所需的數據，避免過多的API調用或依賴定制API的後端開發人員。

但是，有人創建了該數據菜單。如果是您的內部GraphQl API，則可以控制所有內容。但是，如果它是第三方API，例如CMS，則您的控制是有限的。您會被預定義的菜單所困。不允許加法或替代。

在與理智的Simen Skogsrud和KnutMelvær的ShopTalk討論中強調了這一限制。 Sanity是JSON數據存儲和CMS，使用其自己的查詢語言Groq，而不是GraphQl。最初，這似乎是倒退的 - 創建專有語言而不是使用行業標準。

但是Simen和Knut指出了GraphQL用作第三方API時的限制：您僅限於提供的選項。例如，作者的通用GraphQl API可能只提供：

 <code>{ allAuthors { author { name username avatar } } }</code>

如果您需要作者的數量，而不是作者本身，那麼您就無法運氣。您必須獲取所有作者併計算它們的客戶端。

提供GraphQL端點的CMS面對一個選擇：嚴格，有限的數據訪問或擴展和控制訪問的方法。 Sanity選擇了後者，提供了Groq，這是一種足以訪問JSON商店中任何數據的開源查詢語言。

使用GROQ，您不需要API修改即可檢索作者計數。您可以使用以下查詢：

 <code>{ "totalAuthors": count(*[_type == "author"]) }</code>

（注意：這是概念上的；確切的語法取決於查詢的JSON。）

GROQ的優勢：

• 不受限制的查詢：訪問任何數據。
• 簡化體系結構：無中介配置層。

缺點：

• 複雜的語法：更陡峭的學習曲線。
• 有限的集成：減少了多API連接，基於許可的數據訪問等的機會。

以上是最好的（GraphQl）API是您編寫的API的詳細內容。更多資訊請關注PHP中文網其他相關文章！