選擇 GraphQL 的 N 個理由

選擇它就是由於好用啊前端

GraphQL API 具備強類型模式

GraphQL schema 是一個約定,用於指明 API 的功能。數據庫

  • 嚴格的 scheme 定義了 API 所支持的操做 (query, mutation, subscribe)
  • API 文檔會根據對應的 schema 自動生成,後端 API 的設定變得很是簡單

按需獲取,擴展性強

這個其實很直接,前端寫了一段 query,query 裏面直接肯定所須要的數據後端

解決了傳統 REST API 的兩個典型問題:Overfetching 和 Underfetching前端框架

沒必要依賴 REST 端返回的固定數據結構。數據結構

對於老式數據查詢 API 返回的固定的數據結構,咱們甚至要在前端進行額外的處理框架

Overfetching

即返回的數據多於我所須要的數據工具

  • 老式 API
    • 你有一個固定的後臺能夠接收特定的參數,根據參數決定返回的數據庫數據
  • GraphQL
    • 在前端的請求 query 中直接寫我所須要的數據,這樣就不會傳過多的數據回來

Underfetching

即返回的數據少於我所須要的數據fetch

  • 老式 API
    • 我極可能要在請求一個藉口獲得須要的數據
    • 特別是相似於一些鏈接的數據
      • 好比先得到用戶的數據,而後須要再根據每個用戶請求一次後臺獲取用戶的文章數據
      • 這樣明顯就請求了屢次
  • GraphQL
    • 一次請求便可獲得所有

支持快速產品開發

有不少對 GraphQL 支持的前端框架 (Apollo, Relay 等等)編碼

甚至還有 GraphQl Faker 這樣的工具,使得徹底能夠能夠編碼以前將 schema 所有設計好設計

Composing GraphQL API

API 的拼接

能夠自由的將多個API進行拼接

而且能夠進行嵌套式的查詢

有一個豐富的社區

Express 等多個框架都有相應的中間件

調試工具也隨着會不斷的增多

我能夠不用再寫 SQL Server 代碼

這個也能夠算做是一個優點啊

參考文獻

www.jianshu.com/p/03a7d3903…

相關文章
相關標籤/搜索