臉書GraphQL套件Relay團隊開發成員Steven Luscher在臉書總部一場30分鐘的演講「Steven Luscher - Zero to GraphQL in 30 Minutes」,成了認識GraphQL的最佳教材,從中也可快速看到GraphQL如何用一次API取得剛好需要的巢狀資料。(圖片來源/臉書)

已經回不去了!現在覺得RESTful風格非常麻煩,未來我們的API開發,都會支援GraphQL。」iCHEF資深雲端工程師楊靖國強調。

「最大好處是,前端程式呼叫一支後端API,竟然可以事先預期回傳的結果,不用等到伺服器回應後才知道格式不符。」iCHEF另一位資深雲端工程師李中正接著說。

早從2017年秋天開始,這套全臺5千多家餐廳愛用的帳務軟體iCHEF POS,開始引進了這個技術GraphQL。iCHEF兩位後端開發成員,競相點出GraphQL帶來的好處。

GraphQL是2012年時,臉書為了改善手機App操作體驗而開發的API查詢語言,可以網頁應用直接透過API,來描述所需要的資料,來向後端資料庫取得,而不用多次透過Rest API呼叫,才能來拼出所需資料,最直接的好處是,可以減少同一個網頁向後端呼叫的次數,加快網頁應用的反應速度,提供更順暢少等待的用戶操作體驗。

後來,2015年時,臉書將這項技術開源釋出,竟成了許多網路巨頭愛用的網頁資料層存取技術,如Netflix、Airbnb、GitHub、Twitter、Pinrerest、Yelp、PayPal、IBM也都有採用,也有不少大型媒體集團如紐約時報、CNBC、丹麥第二電視臺也導入,作為打造新一代雲端原生應用與大規模網路應用的新資料傳輸架構,JIRA和Trello服務的母公司Atlassian也是GraphQL的重度用戶。而身為開發源頭的臉書,全球每天數十億次的API呼叫,早就改成了GraphQL。

甚至連汽車大廠Audi和BMW,都用GraphQL來打造電動車數位服務與後端系統間串接的資料服務,例如BMW的汽車資料API,就是透過GraphQL來存取資料,而不是透過傳統的RESTful網頁API設計。

全球180萬家企業愛用、3千萬名開發者註冊、代管超過1億份程式碼的GitHub,在最新一版的自家API中,也改用GraphQL,來取代原本的RESTful設計風格。這意味著,未來可以串接到GitHub平臺上的工具或軟體,都將會支援GraphQL的API查詢語言。

過去採用REST架構的API呼叫方式,後端程式負責資料層的處理,而前端程式只負責拿到資料後的呈現處理。當前端程式有資料需求時,只能概略向資料源API提出請求,而由後端程式決定,下達SQL指令到資料庫取出資料,再拋給前端。

但是,REST API每次只能呼叫單一資料源,同一網頁若有多種資料源的需求,例如用戶帳號資料、交易資料、推薦產品清單,就得向三個資料源提出三次API呼叫請求,而且因為後端程式無法得知前端程式目前的處理狀態,只能將符合條件的資料全都拋給前端,這都會徒增了拋給前端的資料量和連線複雜度。

GraphQL的作法則和REST截然不同,GraphQL可以讓前端程式以物件結構來描述所需要的資料,甚至可以使用巢狀結構來描述資料物件的欄位,能更精準也更明確地描述所需要的資料,再向後端API提出資料查詢請求,而後端API則透過Web伺服器上的GraphQL模組或GraphQL伺服器,向不同的資料源所在的資料庫取得資料。

臉書不只開源GraphQL技術,也提供了一整套的GraphQL平臺工具Reley,可供企業建置GraphQL風格的網站,這也是臉書自家網站使用的中介軟體。

現在還有一家新創公司Apollo在2018年11月推出了企業級GraphQL平臺產品,可部署在用戶端或伺服器端,來提供大規模GraphQL API的呼叫。Audi就是用Apollo來打造一個GraphQL API的資料調度層。

因為使用者越來越多,臉書也決定放手,釋出開源專案管理權,成立了GraphQL基金會,捐給Linux基金會這個中立組織來管理,來確保GraphQL的中立發展。

Linux基金會目前正在招募GraphQL基金會的初始成員,要建立一個管理董事會、技術指導委員會和行銷團隊來共同維護,這也讓GraphQL的長期發展,不再完全由Facebook決定,而是透過開源社群來主導,有利於吸引其他科技巨頭的加入,來壯大其發展規模。

根據Linux基金會的網站說明,已有多家大型企業或網路公司加入GraphQL的開發行列,包括了Airbnb、Atlassian、Audi、CNBC、GitHub、Major League Soccer、Netflix、Shopify、紐約時報、Twitter、Pinterest和Yelp。

不過,這個在國外網路公司間開始崛起的GraphQL技術,臺灣採用的實例還不多,iCHEF是臺灣先期採用的企業之一。

iCHEF技術長張峯碩指出,iCHEF第一個GraphQL專案是2017年8、9月展開的集點專案,後來,網頁版庫存報表功能也開始採用,因為效果不錯,連iOS工程師都要求導入。

報表功能是iCHEF POS用戶常用的功能,但因為每一家餐廳的需求不同,想要呈現的報表內容差異很大,iCHEF傳統的作法,不是開發一支複雜肥大的API,將整批資料傳到前端再刪減,就是得為不同的報表,來開發不同的API,但是,改用GraphQL之後,只需用1支API,就能在前端程式中,指定要查詢的資料來滿足特定報表所需,就算不同店家所需的報表欄位不同,也都能靠這支API完成。

儘管中文GraphQL學習資源還不多,不過在iThome今年iT邦幫忙鐵人賽中,有位開發者MeepShop工程師劉鳳軒(代號fx777)一連撰寫了30篇的GraphQL介紹文章「Think in GraphQL 系列」,從入門介紹、工具比較到實際程式碼範例都有,可供有意採用者參考。

建立共通的API資料架構,可減少前端對後端的依賴

早從2017年秋天開始,這套全臺5千多家餐廳愛用的帳務軟體iCHEF POS,開始引進了這個技術GraphQL,例如圖中庫存報表功能就是用了GraphQL。由右到左分別為,iCHEF技術長張峯碩、資深雲端工程師楊靖國和李中正。(攝影/洪政偉)

張峯碩解釋,GraphQL可以提供一套前後端共同的API資料Schema,前端工程師不用等後端修改API,也可以自己操作來取得新的資料組合,「彼此都可以更自主地工作,減少前端對後端的依賴性。」

傳統網頁開發時,API都由後端團隊統一設計,前端程式不會控制後端API傳給前端的資料,但李中正補充,GraphQL可以將前後端要傳輸的資料規格化,清楚地定義出API的資料結構(Schema),「同時規範了輸入和輸出的內容。」他比較:「網頁開發慣用的REST風格只規範了API路徑、傳輸方法,但對於資料則沒有規範。」

正是因為有了一套前後端溝通用的資料結構,iCHEF的前端網頁報表程式,就可以只需呼叫1支API,並用GraphQL語法來指定要回傳哪些資料,「這是傳統API不會支援的作法,傳統API會輸出許多不需要的資料,而GraphQL就可以自訂,不用浪費傳輸資源多拿資料」李中正表示。

GraphQL提供的API Schema設計,是最讓李中正驚艷的功能,因為這項機制,前端工程師可以事先知道,後端API將回傳的資料型態和內容。

「可預測性是GraphQL第一個好處。」李中正解釋,讓前端程式可以取得預期中的欄位,對程式開發來說非常重要,尤其資料欄位格式的變動,很難發現,往往得等到測試階段或實際執行時才能知道。

李中正進一步補充:「尤其串接第三方服務時,常常不可預期對方最後會回傳的內容,但若第三方服務採用了GraphQL,我們就可以省事很多。」

「GraphQL讓前後端有了一套共用的資料結構,可以讓開發團隊的溝通更順暢,」張峯碩點出另一個好處,如此一來,開發初期,前端工程師就能先評估,後端提出的API Schema,並且補充提出自己需要的資料欄位,作為後端工程師設計API之用,「可以將前後端的整合工作,提前到設計階段,不用到了實際程式介接時才發現問題。」掌管技術團隊的張峯碩,更重視GraphQL對前後端開發團隊溝通上的幫助。

而對iOS工程師而言,GraphQL還可以帶來另一個好處,那就「資料格式定義的嚴謹性,」張峯碩補充,現在可以在iOS程式編譯時,就可以確定資料格式的正確性,App若用REST作法,要編譯後實際執行,拿到資料時,才能檢查格式,甚在App中,還得有一支專用的格式檢查程式才行。

尤其,iCHEF的POS軟體中會處理到店家的發票資料,要將這類資料自動拋轉到國稅局的系統,每一個欄位的型態,整數、浮點、字串類型等在送出前都要再次驗證,若有一點錯誤就會上傳失敗。改用GraphQL後,iCHEF在App程式開發階段,就能確認這些型態是否符合政府的規定。尤其過去每次要開發新功能的API時,都還要在API中加入自行開發的格式驗證和轉換機制,現在直接參考Schema設計就可以套用格式轉換功能,輸出成需要的型態。「這正是iOS工程師後來也想用GraphQL的原因,App開發也需要這樣的資料嚴謹性。」同樣地,對網頁版程式而言,也不需要驗證資料格式的程式,可以減少不小的開發工作量。

同一套資料政策,從前端、App到後端資料庫都適用

iCHEF技術長張峯碩表示,GraphQL的好處是省力有效率!不只前後端溝通成本下降,產品開發彈性提高,整體開發效率也能提升。(攝影/洪政偉)

如此一來,「可以讓同一套資料政策,從前端網頁、App到後端資料庫都適用。」張峯碩表示,像iCHEF的產品,有上千個資料欄位要管理時,就常會發生這類前後端資料欄位型別不符的情況。甚至他們曾經有過慘痛的經驗,從前端App好不容易取得的用戶原始資料,卻因資料型別不符,無法彙整到後端的資料庫中,而得一一要求用戶更新App,重新上傳資料的窘況。「資料嚴謹度可以貫穿全程,就不用再擔心這樣的情況。」

越來越多大型企業加入GraphQL的開發,從GraphQL官網上可看到,主流開發語言和網頁技術多已支援,包括JavaScript和Node.JS、C#和.NET、Java、Go、PHP、Python、Ruby、Scala等,開發者只需在Web伺服器安裝對應的模組即可支援GraphQL查詢語言,就可以用來設計API的傳輸風格。另外也有不少好用的工具,例如graphiql就是一款可以在瀏覽器中執行的互動式GraphQL開發工具。

現有四大類GraphQL工具

另外,開店平臺Shopify工程師Robert Saunders也整理了四大類的GraphQL工具,包括了GraphQL用戶端工具,GraphQL閘道端工具、GraphQL伺服器類工具,以及可直接整合資料庫類的GraphQL伺服器。GraphQL用戶端工具最主流的就是臉書的Relay以及Apollo Client程式。熱門的閘道器端工具則有Apollo Engine和FastQL。在GraphQL伺服器上,常見有Apollo Server、GraphQL Ruby和GraphQL Yoga三款。

最後一類伺服器則是可以直接串接到資料庫,讓GraphQL指令透過這類伺服器,轉換成支援不同類型資料庫的查詢指令,一次解決對不同資料庫的連接,常見工具有Prisma、PostGraphile和Neo4j-GraphQL。

iCHEF目前則是採用了Apollo公司的全套GraphQL生態系產品。「相較於臉書功能完整的Reley生態系,Apollo生態系較為輕量化。」張峯碩解釋。

第三方Log服務支援仍不足,得自行強化Log機制

不過,iCHEF並沒有淘汰原本的RESTful API,楊靖國指出,兩者並行,在原有的API路徑上,多了一支GraphQL專用的API,例如iCHEF就所用React框架的Jungle Select選單功能中,自行加入了GraphQL的API路徑。前端工程師再依需求,決定要呼叫原有的RESTful API還是GraphQL API。

另一個採用GraphQL需要注意的地方是Log功能,楊靖國解釋,使用GraphQL查詢API時,網址看起來一樣,但POST傳遞的內容差異很大,因此在Log記錄上無法得知前端程式的行為,容易造成一些第三方Log服務或監控服務的誤判,可能將不同用途的網址合併成同一類來分析。iCHEF的改善方式是,自行在GraphQL的API中,自行增加了需要Log記錄的程式碼,將部分POST的內容也寫入Log。

三階段導入GraphQL,不需一步到位

從一年多的導入經驗來看,李中正建議,導入GraphQL不用一步到位,可以分三階段進行。第一階段,只需讓前後端有一套共用的查詢Schema,「主流開發語言已有支援模組,要實現API Schema不會太難。光是這麼做,就能展現出GraphQL的價值。」第二階段,再進一步整併多種資料請求,透過巢狀資料將多支API整併,一次API呼叫就可以完成多項工作。最後一步再擴大導入全套式的GraphQL框架,例如Apollo或Rely生態系,藉助一套更明確定義的架構來輔助全面性的採用。

GraphQL就像是REST初期3、5年的發展,雖然中文資源不多,楊靖國建議,已有豐富的英文學習教材,光是在GraphQL.org官網上就列出了不少學習教材和支援社群。

另外,jQuery作者John Resig也正在撰寫一本《the GraphQL Guide》的教科書,目前還在Beta版本。楊靖國還推薦,Youtube影片中已有不少用戶分享的影片可參考,新手也可以先從「Steven Luscher - Zero to GraphQL in 30 Minutes」這個熱門的介紹影片開始上手認識。

「省力有效率!」iCHEF技術長張峯碩強調:「前後端溝通成本下降,產品開發彈性提高,整體開發效率也能提升,現在有更好的選擇,就不用浪費時間從事資料格式驗證這類像黑手的工作了。」也因此,不只新開發的功能全面支援GraphQL,他計畫,今年也要讓iCHEF的老舊應用程式,能全面支援GraphQL。

iCHEF技術長張峯碩表示,GraphQL的好處是省力有效率!不只前後端溝通成本下降,產品開發彈性提高,整體開發效率也能提升。


Advertisement

更多 iThome相關內容