從前端開發人員的角度來看，GraphQL 是乙個資料層正規化，它支援樂觀更新、React 元件旁邊的宣告性資料獲取和所見即所得資料。 它由 Facebook 推廣，它提供的不僅僅是 RESTful API。 本文附帶乙個來自生產環境的示例，展示了如何在不影響後端開發人員的情況下將現有的 RESTful API 包裝到前端 GraphQL API 中。
在我從外包商那裡接手的乙個前端專案中，我看到了很多有趣的遺物，比如在頁面之間複製和貼上的無用匯入，以及許多帶有 .bak 但是乙個與另乙個頁面沒有太大區別的舊頁面，孩子般的元件命名等。 API 的使用尤其令人印象深刻，如下所示：
import * as mapi from '../../lib/mapi';// ..省略不相關的** componentwillmount（） mapipie() then(json => )mapi.whoami() then(json => )這看起來有點令人困惑，因為我們看不到 piedata 中的內容。 如果你有更深的層次，很容易脫身cannot read property 'machine' of undefined或undefined is not an object，尤其是當您還使用 ES6 計算屬性值時，除錯時間會變得有點長。
還有很多其他問題，例如必須對 UI 中的資料進行非 null 檢查。
雖然使用 Redux 這樣的資料流框架可以解決大部分問題，但由於現在是重構的時候了，重要的是讓這個重構迭代盡可能長地存在——解決干擾開發人員理解的大問題。 我最感興趣的是資料對我的可見性：
我希望在編寫 UI 時能夠看到資料的樣子，最好資料看起來與我的 UI 結構完全一樣，這樣將資料繫結到 UI 的過程就變得簡單愉快了。 」
現狀是，每次繫結資料都要用郵遞員請求後端看看返回的資料是什麼樣子的，然後呼叫這個API，並從返回的資料中取出一些我需要的資料繫結到UI上，很弱三千取一勺。由於業務變化，我必須同時在乙個 UI 元件中使用多個 API。
我喜歡在常用詞中將字母大寫，例如：deviceid，而後端叔叔喜歡小寫，例如dviceid。哦，我的上帝，他在拼寫時錯過了乙個 e！
理想情況下，後端應該快速跟進業務更改，拆分 API，然後翻閱嬰兒名稱列表，為每個 API 提供乙個新的有意義的名稱。 但顯然後端不會放下手頭的很多東西來配合你改造API，畢竟資料為什麼要跟著UI長一張臉，你覺得你的UI很帥嗎？ 此外，如果三天後需求再次發生變化怎麼辦？ 讓後端再次重寫其餘的端點，他會用他的皮大衣鞭打你。
同時使用 Redux 和 GraphQL 可以解決這些問題。
過去在REST中，我們根據業務將資料劃分為不同的路徑，相當於根據第乙個版本的業務需求，給每一堆資料乙個當時容易理解的名稱，然後希望以後每個業務都使用乙個
古代外包人員的方法export function whoami（） export function pie（） export function entry（） export function districtpie（id） pie ）;export function siteoverview(id) /overview`);export function sitepie(id) /pie`);export function cabinetsswitches(id) /cabinets/switches`);export function sitewarningquantity(id) `與REST類似，我們也可以有易於理解的名稱，但是我們可以直接觀察更小粒度的資料，而不是幻想路徑中隱藏了哪些資料，如下所示：
重構的 API 帳戶 WhoamiType UserType API 資訊條目 API 資料站點概述 戰區資訊，指示地球上有哪些據點或子戰區，並且戰區有自己的**比例餅圖資料 它還可以表示據點的資料，其中可以包括比例餅圖和運輸線列表等資料 型別 PowerentityType這種轉換有兩個直接的好處：首先，您可以直接看到資料來源的樣子！ 不再有郵遞員請求抓取資料，因為你不記得每個資料終結點上有哪些字段可用。 二是它提供了靜態型別檢查，所以你可以在寫型別的時候考慮每個型別應該是什麼樣子，然後把檢查資料可用性的工作放在一邊，專注於業務......
還有兩個間接的好處：乙個是她寫得好像在寫 FlowType 或者 TypeScript，你現在正在給資料新增型別註解，幾個月後你開始學習 Rust 的時候，你會有賓至如歸的感覺，你可以在 21 分鐘內從初學者變成精通。 第二個是可以對資料端點進行標註，可以使用？？ 黑色問號運算子宣告性地表達你對業務的困惑，也可以與 ！ 划船運算子描述資料項的不可或缺性。
我們上面用來宣告型別的語言叫做 GraphQL，GitHub 正在將他們的 API 遷移到 GraphQL，所以你可以檢查它是如何編寫的。 它通常以模式編寫js 檔案，如下所示：
export const typedefinitions = `schema # ..省略其他型別的宣告寫完資料型別宣告後，我們還需要寫架構JS 繼續解釋如何獲取這些資料型別中的每一種以及它們對應的資料。 我們使用分析函式來做到這一點：
// schema.jsexport const resolvers = , args, context) ,username(, args, context) ,password(, args, context) ,token(, args, context) ,id(, args, context) ,name(, args, context) ,companyid(, args, context) ,companyname(, args, context) ,departmentid(, args, context) ,departmentname(, args, context) ,role(, args, context) ,// ..省略其他分析功能，**以實物為準};這可能就是在 UI 中使用它的感覺：
function mapstatetoprops(state) ;const mainpagedata = gql` query mainpagedata($token: string!） const queryconfig = ） => （ 我們配置 GraphQL hoc 在其 props pollinterval： 10000， }props： （=> （connect（mapstatetoprops） Redux classic usage@graphql（MainPageData， QueryConfig） graphql hocexport 預設類 main extends 元件; static defaultprops = , render()更好的方法是插入乙個簡單的 GraphQL 資料端點作為 UI 層和資料層之間的中介。
在這個中介中，我們可以將原本一次性返回一大塊資料的 API 拆分為細粒度的資料型別，可以糾正後端返回的資料中的錯別字，可以檢查資料是否為空，我們來看乙個例子：
// rest2graphqlinterface.以下大部分都是js中的例程，你只需要修改部分模型匯入apolloclient，從'apollo-client';import from 'graphql';import from 'lodash';import from './schemagenerator';import from './schema';import from './models';修改此部分 import houtaidashuconnector from'./houtaidashuconnector';const typedefs = [.rootschema];const resolvers = merge(rootresolvers);const executableschema = makeexecutableschema();const serverconnector = new houtaidashuconnector();const rest2graphqlinterface = ），其中你引入了自己的聯結器 }，graphqlrequestvariables );const client = new apolloclient();export default client;從。
舅舅後端的 RESTful API ->聯結器 ->模型 ->解析器函式 -ExecutableSchema ->rest2graphqlinterface ->ApolloClient ->redux -> UI 的道具 -> UI
正如我們之前所看到的，當我們建立rest2graphqlinterface時，我們寫道：
user: new user(),為什麼會這樣寫？
其實所有的資料採集，也就是請求給後台大叔的RESTful API，我們可以把它放在分析函式裡，但是我們會寫很多重複的**，而且每一點資料我們就要抓一次，這是浪費資源，乙個弱水三千拿一勺喝的概念。
因此，我們抽象出一層模型：
// models.jsexport class user ) async getloginstatus(token) catch (error) async getallmetadata(token) getmetadata(field, token) }export default class houtaidashuconnector token=$`;return promise.try(()=> fetch(`$/$$`then(checkstatus) .then(response => response.json())then(json => return json.data; }從那裡，我們在客戶端設定了乙個輕量級的 GraphQL 伺服器，作為我們和後端之間的中介。 基於程序內測試，這對效能沒有明顯影響，良好的快取邏輯甚至可以加快頁面載入速度。
使用此技術後，資料的採集不會寫入componentwillmount()它不是隱藏在 redux reducer 中，不是隱藏在 redux-saga 生成器中，而是真正深入草根，就在我們的 UI 旁邊，愛房子和黑，一石二鳥，所見即所得，腰部柔軟易推。
這種客戶端-graphql-server的方式也非常適合控制物聯網裝置，畢竟在物聯網裝置中設定server-side-graphql-server是不切實際的，使用RESTful API編寫物聯網控制會比較臃腫，在客戶端將這些資料轉換為graphql是一種可行的方法。
如果您對內容有任何疑問，可以新增China GraphQL使用者組302490951進行交流。 比如有個同志看到我之前寫過關於接力的教程，就問我接力好不好，我什麼都知道：不好用，所以現在改用apollostack
wrapping a rest api in graphql apollo-client issue #