[譯] 怎樣使用GraphQL - 1.介紹

英文原版地址：https://www.howtographql.com/...

---

介紹

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。