# 在 iCHEF 以 Apollo + React 導入 GraphQL 的經驗 - 張登皓

{%hackmd yEJ_rTxzTWa2K450RqmT8w %}

> 從這開始

## 那個 RESTful 的年代

`GET /resource/{:id}/relation/{:relation_id}`

* 一個資源一個 endpoint
* 多個資源 = 多個 request
* 回傳的內容 / 格式不如預期
* 沒有文件
* 在 React 內資料放在 Redux

### 說到 REDUX...
> REACT + REDUX + REDUX-SAGA
* Redux (state management)
* Saga (async management)

### 用 Stoplight 建立 API 文件
缺點:
- 需要前後端額外去維護，容易忘記更新
- 年久失修

## GraphQL
- 用型別定義你的資料

### [Graph"i"QL](https://github.com/graphql/graphiql)
Schema = 文件，可快速試用API
[GraphiQL online](https://lucasconstantino.github.io/graphiql-online/)

### Mutation
= RESTful 的 `POST`/`PUT`/`PATCH`

### RESTful v.s. GraphQL
| RESTful | GraphQL |
|:--------:|:--------:|
| 通常好幾個Endpoint | 單一Endpoint 入口 |
| Request次數多（橫跨多資源時） | Request次數少（大部份時候) |
| API 回你什麼就是什麼 | 回傳資料相對可預期 |
| 文件維護麻煩 | 可做到 Schema 即文件 |

### 有個老問題還是在
- REACT(Container/Component $\uparrow$)
- REDUX(action/reducer $\uparrow$)
- REDUX-SAGA

### Apollo + REACT
- 同時支援 React + iOS
- 把 GraphQL 操作封裝起來
- 內建 Request 機制
- 內建 Cache 機制
- 基本使用超簡單

### Apollo Fetch Policy
- cache-first $\rightarrow$ (預設)優先找 cache ，找不到才抓
- cache-and-network $\rightarrow$ 先從cache顯示，同時抓更新資料
- network-only $\rightarrow$ 無視 cache，永遠從 API 抓
- cache-only $\rightarrow$ 永遠從 cache 拿，拿不到就噴 error
- no-cache $\rightarrow$ 永遠從 API 抓，而且不寫進 cache

### 稍微再做得更好一點
- 在 query 時，包進預設行為，==打包自訂行為的 query==。
- mutation 完順便重抓 query。
- 直接從 cache 讀資料

### 好像不太 GraphQL 的地方
目前還是以 resources 為單位重用 API $\leftarrow$ 較方便管理
> $^{ex.}$已有一取得餐廳的 query，也有一取得 menu 的 query，現在想取餐廳 + menu，需要再一個新的 query 嗎？
No! $\rightarrow$ 若將來 schema 有改，容易漏掉更新。

### Quick Recap
- GraphQL $\rightarrow$ Facebook 發明的一種資料查詢語言

### Hooks 的出現
讓 Component 更 readable $\rightarrow$ Tech Stack: Apollo + Hooks

###### tags: `MW19`