顛覆傳統REST網頁設計架構，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的好處是省力有效率！不只前後端溝通成本下降，產品開發彈性提高，整體開發效率也能提升。