打 api 的次數與頻率

影片中可以看出前端可能一次性打非常多個 api，這初步反映出兩種問題

前端打了很多不必要的 api
- 比對畫面上所需與 response 給的資料，數量差太多了
後端 api 設計方針，致使需要自己在前端想辦法拼湊
- 一般來說第三方 api 是讓大眾每個人不同的需求來串接，因此在設計上可能會將每個 api 拆得非常細，也有機會使前端發生此情形
- 但通常公司都會有自己的後端 api，且主機等級是因應使用者需求去配置的，就會比較要求前端不要打太多不必要的 api
- 之前前端小聚 Danny 會後有聊到的 BFF 會是個折衷的好方案

https://github.com/DoubleTian-tw/pokemon-Gym/assets/38932402/1dbaad35-702c-4dac-87cf-909d6d00f4e4

任務

[ ] 分析 api 的必要性
[ ] 策略如何減少打 api 的次數與頻率
[ ] 實作並演示上述
[ ] @QzCurious 進入到 TanStack Query 的主題時要講解一下 TanStank Query 預設行為理念及經驗

By the way

影片中 un-focus -> focus 就會去打 api 的效果應該是 TanStank Query 的預設行為

Stale queries are refetched automatically in the background when:

The window is refocused

因應 #6 我們若只希望只打一次 api，後面要才對 TanStack Query 設定做調整

我們在聊這個議題的時候，有順便聊到 Chrome DevTools Network 的常用功能 #11，其中我們也有觀察到 https://pokeapi.co/api/v2 的 api 有使用 Http cache 來減輕 server 負擔。這時的 request 其實沒有真的跑出網路，而只是列在上面表示你的網頁有這個 request，且瀏覽器從硬碟直接取回 cached response

多支API需求解釋

https://pokeapi.co/api/v2/type 這支API代表pokemon全部20種屬性的傷害表。

https://pokeapi.co/api/v2/type/1/ 使用第1個normal屬性做舉例，我會取回normal屬性可造成傷害或遭受來自傷害倍數的資料

所以才有必要分別打出20支API的需求，原本有考慮使用graphQL代替，但是提供的資源找不到能夠兜的資料，所以才這樣做。 Refocus的問題，確實不需要再此情況下再次取回資料，所以可以透過設定取消此預設值

BFF的理解

我的理解是，前端不直接與後端溝通，而是透過一個中間人向後端取資料，實作上的優缺點差別可能要實際應用才比較了解

DoubleTian-tw / pokemon-Gym

打 api 的次數與頻率 #14

任務

By the way

多支API需求解釋

BFF的理解