GraphQL 販賣機

拉麵店的販賣機越來越大台了。

前言

我忘記把繪圖板放進行李內，所以只能用手繪的，不好意思。

不知道各位有沒有閱讀過知名大大 Huli 的這篇文章——從拉麵店的販賣機理解什麼是 API，我想基於這篇的拉麵店為基礎聊一下我所了解的 GraphQL。

不，這篇不會教你怎麼用 GraphQL，或是教你怎麼安裝，長那麼大了自己去研究，我只是想要在你腦中對於 GraphQL 還是一個模糊的身影時，提供一個想像的情境，能夠更好的去理解。

API

話說巷口那間拉麵店生意越來越好，客人對於怎麼在餐券販賣機點餐得心應手，想要吃豚骨就按「豚骨拉麵」，想要加小菜的就多按小菜，不喜歡吃的同學可以不要吃。

師傅本人也感到非常開心，加上師傅自己也很喜歡嘗試各種不同的料理，於是常常推出一些期間限定的配菜，像是日式炸雞、飯後冰淇淋、タピオカ開胃菜⋯⋯等等，菜單也開始全方位的開枝散葉，從一開始簡單的拉麵，到現在 變成家庭餐廳 有各種不同的搭配，販賣機也越來越大台。

到現在會來的客人已經無法滿足於單點豚骨拉麵了，每個都想要吃一頓各種搭配的豐盛套餐，所以進來店內都要在餐券販賣機前面按很久，按了好幾個鈕才能湊出他要的全部菜色，某些熱門餐點按到快要壞掉，冷門菜色可能按鈕還跟新的一樣。

所以大家開始思考，要怎麼樣能夠在按一次按鈕的情況下，就把他們想要的餐券拿到呢？

GraphQL

終於在哥兒們的協助下，拉麵店引進了另外一台餐券販賣機，這台販賣機沒有按鈕，只有一個點單輸入孔跟出單口。

沒錯，如果你有吃過一蘭拉麵的話你應該都有填過相同的點單，這個點單包含了所有目前的菜單，勾選好了之後丟進販賣機中結帳，就會跑出一張包含你所有需求跟餐點的餐券了。

這個新的販賣機大幅縮短客人卡在販賣機前面猶豫跟按按鈕的時間，而且，客人只要專注在自己想要吃什麼便勾選即可，不用在一大片按鈕中思考要怎麼湊成自己想要的樣子，大大的減少店內空間擁擠的情況。

師傅覺得非常滿意，可喜可賀。

跟 API 的關係是？

之前的 API 模式雖然直覺方便，但現今的網頁上會同時展現的資料實在太多，很常會有一個畫面但是後面一次請求了十幾個 API，然後在前端湊成畫面需要的結構，有的時候回覆內還會有冗余的資料。

所以 GraphQL 實現了一種方法，只要你的資料定義正確，寫好你的結構之後只要打一次 API，就會回傳你需要的所有資料，不多不少，成功的減少了 API request 的數量。也讓前端畫面在開發時，不用考量如何串 API 兜出你要的資料，只要專注在描述「你所需要的資料上」即可。

沒錯，就跟那些客人一樣，只要專注在「我想要吃什麼」，而不是怎麼按餐券機才能按出自己想要的套餐了。

後記

當然 GraphQL 在實踐還有很多東西沒提，在特定場景也有不是適用的情況，但羅列這些就不是本篇文的目的。

希望這些對正在閱讀的你有幫助，謝謝大家。