《GraphQL實戰(zhàn)——寫給全棧工程師們》以當下流行的移動互聯(lián)網(wǎng)應用開發(fā)為切入點，結合作者多年的前后端實際架構經(jīng)驗，針對目前互聯(lián)網(wǎng)上程序員們對GraphQL的疑問和誤解，并輔以業(yè)界真實案例，對前后端設計中的難點要點分別加以介紹。在前端，本書重點講述了如何提升用戶體驗和響應速度；在后端，主要講解了在高并發(fā)海量數(shù)據(jù)環(huán)境下的設計與優(yōu)化；*后，還介紹了如何讓GraphQL與大數(shù)據(jù)平臺整合來訓練機器學習模型。
《GraphQL實戰(zhàn)——寫給全棧工程師們》內(nèi)容涵蓋前端、后端和大數(shù)據(jù)平臺開發(fā)，非常適合全棧程序員閱讀，也可作為前端程序員、后端程序員、大數(shù)據(jù)工程師、算法工程師和技術型產(chǎn)品經(jīng)理提升知識儲備的參考書。
涵蓋當下流行的移動互聯(lián)網(wǎng)應用前后端和大數(shù)據(jù)平臺開發(fā)，教你如何在高并發(fā)海量數(shù)據(jù)環(huán)境下提升用戶體驗和響應速度
GraphQL能讓前后端數(shù)據(jù)通訊更順暢，提高應用反應速度，加快應用開發(fā)速度，這對全棧、前端和后端程序員來說是非常有吸引力的。目前，GraphQL已經(jīng)被Facebook、Google、 Amazon、Twitter、GitHub、eBay等IT公司接受并投入實際使用。
這是一本寫給一線軟件研發(fā)人員的書。我希望能借本書把自己多年來的系統(tǒng)設計經(jīng)驗（通俗來說就是踩的坑）和大家分享一下。
我并不是因為看到很多硅谷公司——Facebook、GitHub以及Twitter等都開始大量使用GraphQL了，才跟風寫這本書的。恰恰相反，我開始籌劃這本書是因為聽說了非常多的公司內(nèi)部為GraphQL產(chǎn)生了激烈的爭吵，有的公司是前端工程師很想用，但是后端工程師擔心GraphQL性能有問題而拼命阻撓；有的公司是后端工程師很想用，但是前端工程師認為使用GraphQL工作量太大而拼命阻撓。因為前后端的程序員往往會有不同的出發(fā)點和訴求，各公司也會有不同的實際情況，而且使用GraphQL也的確會給已有系統(tǒng)的前后端造成很大的改動和影響，讓很多公司和團隊顧慮重重，一直猶豫不決。我覺得是時候把真實項目中使用GraphQL可能會遇到的種種問題整理出來，寫成一本書來和大家分享了。希望大家讀后能對GraphQL少一些誤解，多一些理性思考，從而做出最符合公司和團隊實際利益的決定。
GraphQL肯定不是包治百病的靈藥，軟件開發(fā)中更是沒有“銀彈”，有所得就必有所失。如果非要說對這個新技術的感受，我更愿意說它是“先苦后甜，痛并快樂著”。我們需要花時間來掌握這門新技術，還要花更多的時間修改已有的系統(tǒng)——這就是“苦”。一旦我們的系統(tǒng)前后端都開始支持GraphQL，那我們的系統(tǒng)就會在靈活性、易用性、兼容性和安全等方面得到很大的提高——這就是“甜”。享受這些好處的同時，往往很多GraphQL服務在某些特定的場景下會遭遇冗余數(shù)據(jù)查詢造成的性能問題——這就是“痛”。最后當我們真正了解GraphQL的工作方式，消除了冗余數(shù)據(jù)查詢，甚至有可能得到了比以前更好的性能和可擴展性——這就是“快樂”。
前面談到了前端和后端，那這本書是更適合前端工程師還是后端工程師呢？其實在我心中，工程師就是工程師，無所謂前端還是后端，這很符合近年來流行的“全棧”工程師概念。但本書對全棧工程師的知識體系要求，可能還要更廣闊——不單單包括前端和后端，還會包括數(shù)據(jù)庫的設計、各種測試技術、容器化部署以及負載均衡等問題。
我開始籌劃這本書的時候，恰逢開源社區(qū)遇到一件趣事，國內(nèi)某程序員到一個還挺有名的開源項目下留言——“不要再開發(fā)了，學不動了”。類似地，我在很多地方推廣GraphQL的時候，也會遇到不少程序員朋友提出質(zhì)疑，現(xiàn)有的開發(fā)工具已經(jīng)很多了，為什么還要花時間去學GraphQL呢？
是啊，如果什么都學，人的精力終究有限，可要是不學，又擔心自己被淘汰。所以我們在學習中要抓住軟件開發(fā)的關鍵——API（應用程序接口）的設計�？梢哉f，一套好用的API是一個軟件系統(tǒng)的靈魂。而API設計也正是貫穿本書的主線，我借GraphQL這個引子，講述各種相關的全棧技術，讓大家可以做出更好的API，更好的系統(tǒng)。
本書涉及的技術多數(shù)是這幾年才出現(xiàn)的，很多技術還在活躍開發(fā)中，本人受自身技術水平和精力所限，只能盡量把這些技術的最新情況介紹給大家。而且到本書出版時，可能有些東西又有了新的變化。所以我會盡量保持更新我在GitHub上的代碼庫，希望讀者朋友也要以自己的實際使用版本為準，不要盲目復制本書上面的代碼。
畢竟GraphQL是非常新的領域，我也在不斷地努力摸索。所以本書會存在一些不成熟甚至有錯誤的地方，歡迎讀者朋友在GitHub或者其他社交媒體上和我討論，我會持續(xù)改進。也希望讀者朋友不要因為一項新技術在初始階段的不成熟、不穩(wěn)定，或者對該技術的一些誤解，就對它產(chǎn)生了成見，從而錯過學習和使用該技術的好機會。
作者
Twitter核心服務組高級研發(fā)工程師，畢業(yè)于美國Syracuse大學計算機科學與工程學院，獲博士學位，曾任國內(nèi)多家公司CTO、技術總監(jiān)、首席架構師。
在前后端以及全棧研發(fā)一線奮斗十余載，專注于高并發(fā)、高可用微服務平臺以及大數(shù)據(jù)平臺架構，擁有重構并優(yōu)化千億級日訪問量微服務以及數(shù)據(jù)采集經(jīng)驗。力求用淺顯的語言來講述親身的實戰(zhàn)經(jīng)驗和國內(nèi)外的先進理論，以滿足中國互聯(lián)網(wǎng)行業(yè)的實際需求。
前言
導讀—本書為快速學習設計
第1章 GraphQL API設計和全棧開發(fā)1
1.1 什么是GraphQL2
1.2 分布式系統(tǒng)2
1.2.1 擴展性3
1.2.2 可靠性3
1.2.3 遠程資源共享4
1.2.4 更強的處理能力4
1.3 C/S架構與API4
1.3.1 C/S架構4
1.3.2 前端與后端5
1.3.3 全棧程序員5
1.3.4 應用程序接口6
1.4 RESTful API的起源與特點7
1.4.1 倉庫保管員的窘境7
1.4.2 REST無狀態(tài)的好處8
1.4.3 RESTful API是否真的無狀態(tài)8
1.4.4 RESTful API是否是數(shù)據(jù)傳輸協(xié)議9
1.4.5 RESTful API的好處是什么9
1.5 RESTful API的主要問題10
1.5.1 數(shù)據(jù)定制的問題10
1.5.2 多次請求的問題10
1.5.3 異常處理的問題10
1.5.4 返回數(shù)據(jù)格式未知的問題11
1.5.5 請求Endpoint和方式過多的
問題11
1.6 GraphQL如何解決RESTful API的
問題11
1.6.1 GraphQL可以自由定制數(shù)據(jù)11
1.6.2 GraphQL可以把多次請求合并為
一個12
1.6.3 GraphQL錯誤以及異常信息
明確12
1.6.4 GraphQL返回數(shù)據(jù)的形式和查詢
請求同構13
1.6.5 GraphQL使用單一的Endpoint14
1.6.6 GraphQL替代了什么14
1.7 GraphQL引發(fā)的疑慮15
1.7.1 GraphQL是否還是RESTful15
1.7.2 GraphQL增大了后端系統(tǒng)設計的
難度15
1.7.3 GraphQL是否會帶來后端性能
問題15
1.7.4 遷移到GraphQL的代價16
1.7.5 GraphQL是該前端驅動還是后端
驅動16
1.8 GraphQL全�？蚣艿倪x用16
1.8.1 Relay17
1.8.2 Apollo17
第2章 GraphQL初體驗—電商API設計18
2.1 基本開發(fā)環(huán)境的搭建19
2.2 和GraphQL互動20
2.2.1 實時交互界面GraphiQL的使用20
2.2.2 通過curl發(fā)送請求21
2.2.3 使用第三方客戶端21
2.3 Schema與定義數(shù)據(jù)類型22
2.3.1 強類型的查詢語言22
2.3.2 服務器端的Schema23
2.3.3 標量類型24
2.3.4 自定義復雜類型25
2.3.5 枚舉26
2.3.6 列表以及對象的列表27
2.4 定義操作28
2.4.1 只讀查詢操作28
2.4.2 可寫修改操作30
2.4.3 訂閱操作31
2.4.4 傳遞輸入類型31
2.4.5 操作也是字段33
2.5 精煉數(shù)據(jù)模型與操作33
2.5.1 接口和繼承33
2.5.2 聯(lián)合35
2.6 精煉查詢36
2.6.1 使用變量36
2.6.2 使用別名37
2.6.3 使用片段38
2.6.4 類型條件39
2.6.5 使用Directive40
2.6.6 后端工程師的福音41
2.7 簡單數(shù)據(jù)驗證41
2.7.1 必填值的驗證42
2.7.2 標量值的驗證42
第3章 電商網(wǎng)站前端開發(fā)44
3.1 GraphQL前端開發(fā)要點45
3.1.1 前端開發(fā)的主要任務45
3.1.2 前端開發(fā)的難點46
3.1.3 前端技術的選型46
3.2 前端React項目初始化47
3.2.1 React特點簡介47
3.2.2 React 整合GraphQL前端系統(tǒng)
設計48
3.2.3 創(chuàng)建React前端工程49
3.2.4 安裝Apollo客戶端49
3.2.5 初始化GraphQL客戶端50
3.2.6 手動發(fā)送查詢51
3.3 只讀數(shù)據(jù)的React UI組件51
3.3.1 構建GraphQL Query查詢51
3.3.2 定義列表元素組件52
3.3.3 定義列表組件52
3.3.4 綁定靜態(tài)查詢和UI組件53
3.3.5 使用Query組件54
3.3.6 從Query組件中接收一個參數(shù)55
3.3.7 數(shù)據(jù)的接收以及出錯處理56
3.3.8 手動刷新57
3.4 修改數(shù)據(jù)的React UI組件57
3.4.1 定義一個帶有變量的Mutation
操作58
3.4.2 使用Mutation UI組件58
3.5 支持訂閱59
3.5.1 什么時候使用訂閱59
3.5.2 訂閱是如何實現(xiàn)的60
3.6 本地數(shù)據(jù)60
第4章 基于Node.js的GraphQL后端61
4.1 GraphQL后端架構思想62
4.1.1 “薄”層設計62
4.1.2 “門戶”設計64
4.1.3 面向業(yè)務設計64
4.2 GraphQL層的職責與實現(xiàn)65
4.2.1 GraphQL層的職責65
4.2.2 GraphQL層的實現(xiàn)65
4.2.3 Resolver函數(shù)與分治策略67
4.3 Apollo GraphQL后端框架68
4.3.1 依賴庫的安裝68
4.3.2 定義和解析Schema69
4.3.3 綁定處理查詢操作函數(shù)69
4.4 詳解Resolver函數(shù)72
4.4.1 Resolver的各種返回類型72
4.4.2 Resolve一個類型72
4.4.3 Resolve一個復雜類型字段73
4.4.4 Resolve一個標量字段75
4.4.5 Resolve一個自定義標量字段77
4.4.6 Resolve一個列表80
4.5 GraphQL后端驗證以及錯誤
處理81
4.5.1 簡單方式81
4.5.2 使用自定義標量類型進行驗證82
4.6 異步IO84
4.6.1 基于異步非阻塞IO的JavaScript
實現(xiàn)84
4.6.2 同步還是異步85
4.6.3 異步Resolver85
4.7 使用JavaScript開發(fā)后端服務的
問題86
第5章 基于Go語言協(xié)程的GraphQL服務88
5.1 使用協(xié)程和上下文89
5.1.1 使用協(xié)程的原因89
5.1.2 協(xié)程和GraphQL服務90
5.1.3 上下文和作用域90
5.1.4 派生上下文91
5.2 Go語言的Web服務和中間件92
5.2.1 構建Web服務92
5.2.2 Web服務中間件93
5.2.3 基于中間件的后端架構94
5.2.4 數(shù)據(jù)收集中間件95
5.2.5 數(shù)據(jù)庫會話中間件95
5.3 G
書單推薦
