iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 19
0

本系列文以製作專案為主軸,紀錄小弟學習React以及GrahQL的過程。主要是記下重點步驟以及我覺得需要記憶的部分,有覺得不明確的地方還請留言多多指教。

前端部分告一段落,今天開始進入架設後端GraphQL API的部分。

而在動手實作前,慣例先簡介一下GraphQL是什麼。

網上已經有不少文章介紹過GraphQL,希望這篇記錄我理解的部分能帶來新的學習切入角度,若有不正確的部分還請多加指正。

特性

GraphQL是種為API設計的查詢、修改語言,最初是Facebook為了對應日益複雜的資料架構,需要更簡潔、更易理解的資料請求方法,供Facebook應用的開發者使用。

接下來的介紹我想搭配實際操作會比較好了解內容,就借用Github GraphQL API提供操作環境。

在右上角登入github帳號後,就能開始操作畫面裡的輸入框

左半邊是輸入GraphQL指令的部分,已經有提供現成的指令,只要點擊左上運行鈕,就能在右半邊看到API回覆的資料。

要你想要的

目前的query指令是這樣:

query { 
  viewer { 
    login
  }
}

對於viewer這個query,我們只要求回傳login的資訊。

但其實viewer能夠提供的資訊不只這樣,可以在login底下加入name的資訊,並點擊運行鈕。

然後右邊回覆就多出了name的資訊。

這是GraphQL第一個便利點,要你想要的,若是REST API當請求後會回傳哪些資料欄位都是預設好的,常常會有多餘、當下用不著的資訊,但在GraphQL,需要多少就拿多少。

另外這個做法的好處,就是客戶端能夠清楚預期自己會收到哪些資訊,畢竟就是自己要求的,不用在發完請求後再打log出來看到底回傳了什麼。

在進一步的好處,若哪天某個資料欄位不再需要了,比較方便調查有哪些客戶還再用這些欄位,因為請求都要帶上需求欄位資訊。若是REST API,哪個客戶有用到這個欄位,是很難調查的,畢竟都是一整包收去用,哪些欄位被用到都不清楚。

一個請求、多個來源

接著在viewer之後加上repository這個query:

按下運行後回覆會一併將viewr跟repository的需求欄位回傳。

看似理所當然對不對? 但這種操作在REST API的話,一般會向兩個不同的url發送請求,分別從兩個url收到回覆後再合併資料運用。不過GraphQL能夠以一個請求處理,降低發送請求的頻率。

型別定義

一個GraphQL服務開始於資料類型(type)與各類型包含的欄位(fields),以及跟跟其他資料類型的關聯,而當收到query後就會根據這些資料類型定義,進行關聯搜尋與確認query請求的資訊是否存在。

關於型別定義的撰寫會在實作環節提到,這邊可以先從Github GraphQL API看看已經定義好的型別長什麼樣子。

將游標停在viewer上等一下,可以看到Query.viewer的定義,需求回傳的是User這個Type,點擊User在螢幕最右邊看看它的定義。

一開始可以看到簡單的User type介紹,Implements是指跟其他type的關聯,最下面的一長串Fields就是這個type能存取的欄位,裡面可以找到我們前面請求的name與login欄位。而每個欄位都有對應的型別,像是String或是Int。

當API根據這些型別處理請求時,若有資訊的型別錯誤,就能跳出對應的錯誤提示。

缺點

GraphQL提供了更靈活的資料請求方式,也讓前端人員更容易掌握請求的內容,並且同時也進行型別管制,不過由於GraphQL運作上就是單一 url + POST json請求,也會造成一些功能的缺漏:

  1. 後端難以建立暫存(cache): 請求都在單一url上,無法像REST API根據不同url建立暫存。
  2. 無法上傳檔案: GraphQL功能建立在POST application/json上,無法改成檔案上傳請求。

不過上述兩點現在都有第三方套件協助解決,之後看看有機會就來實作。

References:

tags: 2020Ironman React tutorials

上一篇
仿Trello - 串接Unsplash API
下一篇
仿Trello - 建立Apollo GraphQL server
系列文
React + GraphQL 全端練習筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言