在現代前端開發中，載入進度條（Loading Indicator）是提升用戶體驗不可或缺的元素。無論是資料查詢、表單送出還是頁面切換，適當的 loading 效果都能讓使用者明確感受到「系統正在運作」，降低誤解或焦躁情緒。
但實務上，開發時本機 API 幾乎都「秒回」，要測試前端 loading 條顯示效果變得很困難。這時，在 GraphQL API 層加延遲，是一個快速又方便的解法。
為什麼要在 API 層加延遲？
- 模擬真實網路環境： 使用者在生產環境下的網路品質、後端負載、查詢資料量都可能造成延遲。
- 驗證前端行為： 測試前端 loading 條、載入動畫、Skeleton UI 等效果是否如預期顯示、隱藏。
- 發現潛在 UX 問題： 讓你能真實感受到等待時的流程與介面，是否需要優化提示或調整布局。
如何在 GraphQL API 加延遲？
假設你用 Node.js（Express）+ Apollo Server/Prisma 實作 GraphQL API，可以在 resolver 裡加一行：
// 假設在 resolvers/Query.js
const resolvers = {
Query: {
switches: async (parent, args, context) => {
// 人工延遲 2 秒（2000 毫秒）
await new Promise((resolve) => setTimeout(resolve, 2000));
// 原本的資料庫查詢
return context.prisma.switch.findMany();
},
// ...其他 Query
},
};
這樣當你在前端呼叫 switches 這個查詢時，API 一定會等 2 秒才回傳資料。前端 useQuery 的 loading 狀態會維持 2 秒，進度條就能完整呈現。
搭配前端 Vuetify/Vue 進度條
例如你的前端用 Vuetify v-progress-linear 做資料表 loading：
<v-progress-linear v-if="loading" indeterminate color="blue" height="3" />
<v-data-table :items="items" :loading="loading" ... />
只要後端回應變慢，這條進度條就會清楚顯示。
測試建議與注意事項
- 開發階段建議隨時調整延遲秒數，讓不同情境（1 秒、3 秒、5 秒）都測試一次。
- 記得專案進入正式環境前移除延遲，避免影響實際效能。
- 若需臨時測試，也可以用 Chrome DevTools 的 Network Throttling（如「Slow 3G」）模擬網路慢速，但後端加 delay 更貼近實際後端查詢壅塞狀況。
- 延遲只需加入在你想測試的特定 resolver，不一定全部都要加。
小結
API 層加延遲是開發時極實用的小技巧，可以大幅提升你對「使用者等待過程」的敏感度，也能驗證前端進度條/動畫是否流暢、不閃爍。建議在每個新功能開發時都做一次 loading 條測試，確保你的 UI 真的友善！
如果你是團隊開發，也很適合教大家用這招，大家寫出來的前端畫面才會更一致、專業！