GraphQL前言

何謂GraphQL?

GraphQL本身不是一種框架更不是一種程式語言,筆者認為可以解讀成一種有助於前端和後端工程師在開發時的規範.也可以想成一種可以替代前端使用fetch或是axios的工具.

我要怎麼使用GraphQL?

前端

以前端來說,其實目前不論使用的是React,Vue或是angular都可以額外的安裝package去完成這件事情,目前絕大多數人使用的為Apollo 筆者則是使用Meta的親兒子Relay,不論你使用哪一種都可以,這些package的選擇終究只是用法的差異,並不會影響到我們的結果

後端

以後端來說,不論是使用Node.js,Go或是Java等後端常見的程式語言,也都各自有適合的package去完成這件事情，筆者較熟悉的後端語言是Golang,所以選用了gqlgen,和前端同理,不論你選擇了哪一種程式語言和package,都不會影響到我們最後的結果

未來的範例前後端分別使用React+Relay和Go+gqlgen.如果對React和Go都熟悉的讀者應該可以很好理解,如果您不熟悉它們也沒關係,並不會影響到您學習GraphQL的概念,只是語法上的不同而已

Why use GraphQL? 對我的人生有什麼差異?

以下是筆者使用GraphQL一些時間後,列出與RESTful比較下的優點及一些小缺點.(僅代表筆者的想法)

優點(特色)

1.可以產出類似swagger的api文件(Playground),對於後端來說不用額外做一份api文件非常便利,對於前端來說也可以直接享有一份簡易的api文件,如下圖

2.避免Over-fetching(後面有更明確的介紹,先知道有這件事情即可):前端可以自己決定發送一次查詢api後想要得到的value(當然後端要先定義好),如下圖


可以看得出來,兩隻一樣的api,只是把request body的內容抽換掉,就可以得到不同的結果,雖然看起來好像沒什麼影響,但如果今天query的資料量比較大時,前端可以決定想要收到的資料時,可以透過上述方式,解省傳輸的流量進一步減少前端loading的時間.

3.避免Under-fetching(後面有更明確的介紹,先知道有這件事情即可):前端可以合併多個查詢及新增(更新,修改)並且組成一支api,發送給後端,可以避免多個api要多次發送api,讓前端需要一直await的問題

可以看得出來同一隻api裡面包含了query patient和user的行為在裡面，如果是原本的RESTful API，可能要打兩支API或是在後端的行為上寫一隻把兩個合併再一起的API，不論是哪一種作法都沒有非常理想，前者在await上可能要額外花費許多時間(外部的檢查，如:SSL及DNS)，後者的話會額外增加後端的複雜度，導致維護不便

我們也不要一昧的捧GraphQL,以下來看一些它的缺點

一些小缺點

1. 在發生錯誤時,後端會回傳200的http status code,並把錯誤內容包在response裡面
   為了能更明確的看出http status code，使用postman來測試(用Playground會得到一些的結果)
   
2. 上述優點的第三點同時也是缺點,當一個query夾帶了多個查詢時,若有其中一個有錯誤,會導致整個api報錯,讓前端的畫面看起來死的很淒慘
3. 不論前端是使用CRUD的哪一種api請求,一律都是發POST給後端,需要透過field name(下一篇會介紹)才能比較明確的知道該api的行為

以上皆為個人使用GraphQL後的一些心得,若有錯誤,還請不吝指教.接著會介紹GraphQL一些基本的做法還有如何在前後端實作

官方說GraphQL is the better REST

這邊有一個官方的影片,因為影片有點久我就把我看到後覺得是重點的部分寫下來
GraphQL官方影片-GraphQL is the better REST

1. GraphQL 的開發是為了滿足在client和server端在發開時的需求,可以更有效率及靈活性
2. 他這邊舉了一個實務的情境有一個畫面會顯示使用者的個人資料,下面會呈現他曾經建立過的文章,最後還想顯示最新的三個關注者,以REST API架構來說有三隻api分別是 /user/{id},/user/{id}/posts和/user/{id}/follows
   
   在第一步時我們往往會拿到一些不需要的資料,比如說地址或是電話,其實我們實際上只需要姓名就好了,再來不論是拿到建立過的文章或是最後三個關注者的資料都有相同的問題,其實也是前面有提到的Over-fetching,甚至最嚴重的是我們只需要三個關注者者,但實際上可以拉取了上萬個我們用不到的關注者.
   
   
   可以來看看GraphQL提出的做(解)法
   
   
3. Under-fetching-意思為一個endpoint的return無法滿足實務上的需求,導致你需要叫x個endpoint的情境,會造成需要n+1-request problems個request的數量.雖然在在REST的架構下,後端可以新寫一個endpoint滿足實務上的需求,再讓前端更改api,但實際的困難點是,每一次前端的UI有變動,除了後端要修改以外,前端也可能不只一個地方要修改,他們認為這對產品的迭代來說風險很高.
   而GraphQL提出的解法為-都交給前端處理,後端不要去改動endpoint.
4. Benefits of Schema & Types-所有的資料都是由Schema定義好的也有強型別的特性,前後端都很明確的知道可以用什麼,什麼可以用,或是資料應該是什麼樣子,跟REST比起來比較不會有濫(誤)用的問題

點我開始學習GraphQL