GraphQL初識

本章節部分資料來源於：https://graphql.com
GraphQL最早是由FaceBook公司所推出的新一代資料介面標準。在2012年開始開發，最初的版本釋出在2015年，2018年7月從FaceBook脫離出來，成為一個獨立的、開源的專案。

為什麼要是用GraphQL

其實任何軟體的核心都是對資料的儲存、查詢、處理和展示。如果把基於web的軟體專案分為前、後臺的話，後臺主要的任務是儲存、處理，前臺的主要任務則為查詢和展示資料。但是往往後臺所儲存的資料結構和前臺所需要的資料結構有一定的差距，例如後臺大部分資料庫仍然採用關係型結構（當然也有NoSQL的諸如MongoDB，圖形資料庫Neo4J等，但主流仍然是採用關係型資料庫如MySQL，Oracle等，畢竟這些產品在穩定性和效率上有多年積累下來的口碑），而web端則需要圖形、樹形的資料結構。這樣則需要在前、後臺之間開發資料介面API。
在GraphQL之前，主要是採用RESTful這種介面規範。其核心思路是通過強化URI內容，向後臺傳遞所要查詢的關鍵引數諸如表格、欄位、欄位值等等。而後臺接收到這些引數之後則根據URI的不同內容，設計出不同的Router和相對應的業務處理邏輯，獲得相應的處理結果後，再以統一、規範的資料格式（諸如JSON格式）返回給前端使用。（關於RESTful介面規範，可參閱：http://www.ruanyifeng.com/blog/2014/05/restful_api.html，https://restfulapi.net/）
但是隨著前端所需要展現的資料越來越複雜，而RESTful中的URI能傳遞的引數資訊比較有限，這就會出現前端所要求資料和後臺提供的資料不匹配的情況。如前臺通過Restful規範的URI傳遞一個id引數，那後臺很有可能把與這個id相關的所有資料都傳遞給前端，而由前端自行篩選哪些資料是需要的資料，這樣就會帶來大量的資料冗餘問題。對於大型網站的話，很有可能會帶來資料庫伺服器負載增加、速度變慢等問題，為此GraphQL應運而生。

GraphQL特點

GraphQL本質上來說是一個資料查詢的API。它並不需要繫結任何的特定資料庫或者儲存引擎。你只要定義好一個GraphQL的API，則不需要關注後臺具體採用何種資料庫或這儲存引擎。
我們來看一個例子：

{
  hero {
    name
    # Queries can have comments!
    friends {
      name
    }
  }
}

這是一個GraphQL的query語句的例子，當它傳送GraphQL伺服器上執行的時候，會返回下面的一個結果：

{
  "data": {
    "hero": {
      "name": "R2-D2",
      "friends": [
        {
          "name": "Luke Skywalker"
        },
        {
          "name": "Han Solo"
        },
        {
          "name": "Leia Organa"
        }
      ]
    }
  }
}

由此可見，GraphQL查詢結果結構即為查詢語句的定義的結構，即所謂的“ask exactly what you want.”