本系列文以製作專案為主軸，紀錄小弟學習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請求，也會造成一些功能的缺漏:
不過上述兩點現在都有第三方套件協助解決，之後看看有機會就來實作。
2020Ironman React tutorials
iThome鐵人賽
看影片追技術