Flux再進化：Introducing Relay and GraphQL譯

關於Relay與GraphQL的介紹

原文：Introducing Relay and GraphQL
視頻地址（強烈建議觀看）：https://www.youtube.com/watch?v=9sc8Pyc51uU

React應用如何獲取數據

現在，Web開發從單純的構建界面變得更加接近應用（application）。數據獲取是一個棘手的問題，特別是當應用變得複雜的時候。在React.js Conf上，Facebook公佈了兩個項目，用於幫助開發者簡化數據層的問題，即便面對擁有衆多參與者、複雜得像Facebook同樣的項目。

這兩個項目——Relay和GraphQL——已經在Facebook的產品中使用了一段時間了，咱們很高興未來可以把他們貢獻給開源社區。如今，讓咱們先分享一些額外的信息。

什麼是Relay

Relay是Facebook在React.js Conf（2015年1月）上首次公開的一個新框架，用於爲React應用處理數據層問題。

在Relay中，每一個組件都使用一種叫作GraphQL的查詢語句聲明對數據的依賴。組件可使用this.props訪問獲取到的數據。

開發者能夠自由地組合React組件，而Relay負責把不一樣組件的數據查詢語句（原文的query）集中高效地組織並處理，向組件提供精確粒度的數據（沒有多餘數據），當數據變化時通知相應組件更新，並在客戶端維護一份包含全部數據的數據緩存store。

什麼是GraphQL

GraphQL是一種用於描述複雜、嵌套的數據依賴的查詢語句。它已經在Facebook的原生APP上使用了多年。

在服務器端，咱們經過配置將GraphQL與底層的數據查詢代碼映射起來。這層配置使得GraphQL能夠訪問不一樣的底層存儲系統。Relay使用GraphQL做爲數據查詢語句，但並不指定GraphQL的具體實現。

理念

Relay是根據在Facebook構建大型應用的經驗而誕生的。咱們的首要任務是讓開發者能以符合直覺的方式構建正確、高性能的WEB應用。它的設計使得即便是大型團隊也能以高度隔離的方式應對功能變動。獲取數據、數據變動、性能，都是讓人頭痛的問題。Relay則致力於簡化這些問題，把複雜的部分交給框架處理，讓開發者更加專一於應用自己。

將查詢語句放到視圖層代碼中，開發者只需查看組件自己的代碼就能夠輕易理解組件的行爲：不須要考慮和理解組件所處的上下文。組件能夠在任何地方重用，而不用修改它的父組件或服務器端代碼爲它傳遞或準備數據。

譯者注：上圖在原博中沒有，爲視頻中截下來的代碼截圖，展現了Relay的query與展現代碼混雜，圖中黃色部分既爲GraphQL語句。

代碼混雜（原文爲Co-location，意爲將數據查詢語句放在視圖組件代碼中）將開發者帶入了「幸福的坑」(猜想此處的「坑」是指這種混雜看起來像是反模式)，他們能夠細粒度地獲取須要的數據字段，而對粒度的聲明就在視圖層代碼上。這意味着性能天然地獲得了提高（更難獲取冗餘數據），而組件變得更加健壯（一樣得益於顯式的數據依賴聲明，字段缺失的狀況也得以免，組件不會在運行時由於渲染缺失的字段而掛掉）。

Relay經過維護組件與數據間的依賴——在依賴的數據就緒前組件不會被渲染——爲開發者提供更加可預測的開發環境。另外，數據查詢語句是靜態聲明的（換句話說，咱們能夠在渲染前抽離分析整個組件樹的查詢語句），而GraphQL語法提供了對有效數據的準確描述，所以咱們能夠經過校驗數據查詢語句來儘早地發現開發者所犯的錯誤。

組件只能訪問在數據查詢語句中聲明過的字段，即便其它字段已經被緩存在數據Store中（其它組件可能須要這些字段）。這杜絕了隱式的數據依賴致使的潛在bug。

經過統一的抽象來處理全部的數據獲取工做，咱們得以處理不少在應用中廣泛而重複的問題：

• 性能： 全部的查詢都通過框架統一處理，不然會變得很是低效。重複的查詢會被自動合併並批處理成高效的、最小化的。一樣地，框架知道哪些數據以前被請求過，或者哪些請求正在進行當中，所以數據查詢能夠自動去重至最小化。
• 監聽： 全部的數據都存放在惟一的Store中，對該Store的讀取也由框架管理。這意味着框架了解哪一個組件關心哪些數據，數據變化時哪些組件應該從新渲染；組件再也不須要自行監聽數據更新。
• 公共範式： 能夠更容易地構造公共範式。在大會上 Jing給出的例子是分頁：若是你在初始狀態有10條記錄，翻頁意味着聲明你總共須要15條數據（注：每頁5條記錄，這兒的翻頁相似於下拉刷新，新數據append到當前的後面），框架會分析出你須要和數據和現有數據之間的差值並構建最小查詢，而後在服務器返回數據時更新視圖。
• 簡化服務器端： 相比於分散的響應端點（響應每一個action，每一個路由項），GraphQL接口能夠做爲底層資源對外的統一門面
• 統一處理數據變動： Relay有統一的處理數據變動（寫數據）的模式，在概念上它被抽象成了數據查詢模型。你能夠理解成一次數據變動由兩條數據查詢語句組成：一條是帶有反作用的——你提供描述變動的變量（例如：往一條記錄中添加一條評論），另外一條則指明瞭當變動完成後更新View視圖所須要的數據（例如：評論總數），而後數據像正常的數據流同樣被框架處理。咱們能夠樂觀地當即渲染客戶端，即在假設數據變動成功的前提下更新視圖，在最後提交更新，若是服務器端返回異常則嘗試重試或回滾視圖。(注：此段翻譯不是太有信心，原文的表述看得不怎麼明白)

與Flux的關係

在某些方面Relay的靈感來自於Flux，可是理論模型變得更加簡化。Relay用緩存全部GraphQL數據的惟一的store代替了Flux中分散的store；相對於Flux由組件自行監聽數據變動，Relay用框架管理數據訂閱和視圖更新。 Instead of actions, modifications take the form of mutations

在Facebook，咱們有徹底使用Flux的項目，有徹底使用Relay的項目，也有二者兼用的項目。一個咱們逐漸意識到的模式是讓Relay管理應用級的數據流，而讓Flux管理數據以外的應用狀態。

開源計劃

咱們正在努力讓GraphQL（一個特殊的，參考級的實現）和Relay早日開源（暫時尚未明確的時間，但咱們對於達成這一點很是興奮）。

同時，咱們會以博客（還有其它頻道）的形式提供愈來愈多的信息。隨着咱們距離公佈開源版本愈來愈近，你能夠期待更多的細節、語法和API描述等等。

走着瞧吧

譯者後記：

以前有看過Flux的相關資料，也試着本身寫過基於Flux的框架和demo，但總以爲Flux更像一個半成品：對服務器端交互的問題沒有很好地回答，手工訂閱的action一定會面臨膨脹等……

Relay像是Flux進一步成熟和發展的產物，某種程度上說甚至有了Angular的影子：更細粒度的聲明式的數據依賴管理，框架監聽處理數據變化。

目前的資料還比較少，不少問題須要等待更進一步的資料或代碼才能弄明白，不過Relay能夠說是繼Flux後往前走的一大步，很是值得繼續關注