打 api 的次數與頻率

[QzCurious]

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

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

bandicam.2024-02-22.16-33-42-344.mp4

任務

• 分析 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

[DoubleTian-tw]

多支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的理解

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