亚洲天堂第一区,九九99在线视频,九九九精品视频免费

findPost(id: <postId>) {
id
title
content
author
comments {
id
comment
commentedBy
}
}
}

正如你所看到的，我們僅僅通過單個請求獲取到了所有必要的數據。所以當你想要一個新字段你只需要將它添加進查詢中，它將在響應中呈現

2、強類型

GraphQL 被強類型模式所控制。這些類型既可以是原始的也可以是派生的。強類型系統允許 API 自文檔化，從而使客戶端知道在查詢特定查詢時會的到什么響應。

3、客戶端驅動

GraphQL 提供了一種聲明式語法，以便客戶端精確地指定它們所需的字段。這消除了由于客戶端根據模式向 GraphQL 服務器聲明其數據需求而導致數據冗余和不充分的可能性。

4、API 演變

因為在 GraphQL 中一切都是模式（schema）驅動，新增字段不會影響現存字段，而且 GraphQL 還為廢棄字段提供 @deprecated 注釋，所以對 GraphQL 的擴展并不是問題。這就消除了 API 版本控制的需要。

5、傳輸層不可知

這是 GraphQL 的一個非常棒的優點。 API 服務器可以通過類似 HTTP, HTTPS, WebSockets, TCP, UDP 等協議進行信息交換。這是因為 GraphQL 甚少關心信息如何在客戶端與服務器之間進行交換。

GraphQL 的缺點

哇，GraphQL 很棒，這是一個眾所周知的事實。但是世界上的任何東西都是有缺陷的，GraphQL 也無法置身事外。

1、緩存功能不成熟

GraphQL 不支持瀏覽器和移動手機緩存，這一點區別于使用本地 HTTP 緩存機制的 RESTful 服務，因此我們要為實現 GraphQL 緩存付出額外努力。雖然有 Relay 這樣的工具提供了一些緩存支持，但是它們還沒有 RESTful 服務使用的緩存機制成熟。

2、檢驗與錯誤報告

RESTful 服務利用 HTTP 狀態代碼來處理可能遇到的不同錯誤。對開發人員來說，這使得 APIs 的檢驗變得非常簡單和輕松。但是使用 GraphQL 服務總是返回 200 OK 響應。一個典型的 GraphQL 錯誤消息是這樣的，狀態碼為 200 OK 。

{

    errors: [

        { 

            message: 'Some error occurred'

        }

    ]

}

這使得處理錯誤場景非常困難，并且使得檢驗過程非常麻煩。

3、暴露模式和資源攻擊

和 RESTful 服務不同，GraphQL 服務要求客戶端必須知道要查詢的數據模式。如果您將 API 暴露給第三方，則基本上暴露了您的內部數據結構。必須非常小心，因為客戶端不用很高的代價就可以發起連接查詢，這可能會導致服務器上的拒絕服務（DoS）攻擊。

4、安全 – 身份驗證和授權

GraphQL 社區仍然對如何處理 GraphQL 服務的安全部分感到困惑。仍然沒有集成身份驗證和授權的原生解決方案。它通常被抽象到業務邏輯層來授權用戶，但是我們是否真的必須解析和驗證一個未經驗證的用戶的查詢仍然是 GraphQL 領域中的一個問題。

5、N + 1 次查詢問題

在 RESTful 服務中，很容易記錄執行的 SQL 查詢并進一步優化它。但在 GraphQL 的情況下，解析性質是動態的，因此很難獲得精確的查詢并進一步優化它。有時，字段解析器可能會導致 N+1 次查詢問題和復雜的連接操作。但是 Facebook 正在開發像 DataLoader 這樣的工具來解決這個確切的問題。所以，也許在未來，這不會是一個不利因素。