介紹
GraphQL是一個新的API標準，具有高效，強大，靈活的特性，旨在替代REST模式。GraphQL由Facebook公司開發並開源，目前由來自世界各地的公司和開發者共同維護。
API已經在軟體基礎設施中變得無處不在。總之, 一個API定義了客戶端如何從伺服器載入資料。
作為GraphQL的核心點，它支援宣告式資料獲取，客戶端可以從介面中，精確指定需要的資料。不同於多個後端介面返回固定的資料結構，一個GraphQL服務僅僅暴露一個介面，並精確的響應客戶端想要的資料。
GraphQL - 一種API查詢語言
今天，大多數應用都需要從伺服器獲取存在資料庫中的資料，API需要提供獲取資料的介面，以滿足應用的需要。
GraphQL往往被誤認為是一個資料庫技術。這是不正確的，GraphQL是一種API查詢語言，而不是資料庫的查詢語言。所以說，它是資料庫無關的，可以用在任何使用API的場景中。
一個更有效的REST模式替代者
REST模式是目前流行的從服務端獲取資料的方式。 當REST模式提出時，客戶端程式都相對簡單，並且發展速度也遠落後於目前。REST模式也能很好的適用於諸多應用。然而，過去幾年裡，API領域有了根本性的變化。特別是，以下三個因素，對API的設計方式發出了挑戰：
1.日益增多的移動端使用，需要資料載入過程更有效率
在移動端使用量變多的場景下，低功耗的裝置和較差的網路環境是Facebook開發GraphQL最初的原因。GraphQL通過最小化網路傳輸時所需要的資料量，改善了這種環境中的應用使用情況。
2.各種不同的前端框架和平臺
面對各種各樣的前端框架和不同終端裡的應用，開發並維護一套通用的API，用來滿足左右需求，變得越來越難。但是通過GraphQL，客戶端可以精確獲取所需資料。
3.快速開發&快速新增特性
持續部署已成為許多公司標準,快速迭代和頻繁的產品更新也變的不可或缺。如果使用REST模式API，服務端往往需要修改對外暴露的資料介面，來滿足客戶端在需求和設計上的變動。這阻礙了快速開發和產品迭代。
歷史，環境和採用
GraphQL並不是React開發者專用的
Facebook在2012年開始，在他們的原生移動應用中使用GraphQL。但有趣的是，GraphQL目前主要被採用在Web相關技術環境裡，反而在移動應用中獲得的影響力很小。
Facebook的第一次公開談論GraphQL是在React.js Conf 2015，並在不久之後宣佈了他們的開源計劃。因為Facebook總是在結合React談論GraphQL，所以對於非React開發人員來說，需要花費一段時間才能明白GraphQL絕不是一個限於使用React的技術。
Dan Schafer & Jing Chen在React.JS Conf 2015公開介紹GraphQL。
一個迅速發展的社群
事實上，GraphQL可以在所有客戶端與API通訊的地方使用。有趣的是，包括Netflix和Coursera的一些公司也曾試探過相似的方案，使API互動更有效率。Coursera設想了一種類似的技術，讓客戶端指定其資料要求，Netflix甚至已經開源了他們的Falcor解決方案。但在GraphQL開源後，Coursera取消了計劃，並搭上了GraphQL的車。
今天，GraphQL被許多不同的公司（如GitHub，Twitter，Yelp和Shopify）用於生產。
儘管如此年輕的技術，GraphQL已經被廣泛採用。點選瞭解還有誰使用GraphQL。
列出幾個專注於GraphQL的組織，有GraphQL Summit、GraphQL Europe、GraphQL Radio、GraphQL Weekly。