Storefront API 的成本不只看呼叫次數。工程時間會花在 query 設計、型別、cache、錯誤與重試、market context、cart 狀態、bot 保護、版本升級和監控。若估價表只寫「串接 Shopify API」，上線後的維運範圍會非常模糊。
先用頁型與顧客旅程列出資料需求，再決定 query。不要從 schema 中挑出所有可能欄位一次取回。
建立 query inventory
列出首頁、集合、商品、搜尋、推薦、cart 和帳號頁使用的 query 或 mutation。每一筆記錄觸發位置、欄位、變數、market、cache policy、可接受延遲和失敗畫面。共用 fragment 可保持欄位一致，但也要避免一個超大 fragment 讓所有頁面過度抓取。
使用 GraphQL code generation 或相等的型別流程，讓 schema 變更能在 build 時被發現。Production 不應靠手寫資料形狀猜測 API 回傳。
理解限制的真正含義
Shopify 的 API limits目前說明 Storefront API 對真實買家請求沒有固定 request-per-minute 限制，但 automated traffic 會受限制，惡意請求也可能收到 430 Shopify Security Rejection。Checkout 建立另有 throttle，超過時可能回傳 throttled response。
「沒有固定上限」不代表可以無限制重複查詢。大量未快取請求會增加前端延遲、hosting 成本和故障表面，也可能因 bot 或錯誤迴圈造成流量異常。
Cache 依資料新鮮度分層
品牌內容、集合敘述和多數商品資訊可以有較長 cache；價格、availability、cart 和 customer context 需要更短或不共用 cache。Cache key 必須包含會改變結果的 market、語言與顧客情境，不能讓不同市場看到錯誤價格。
設計 revalidation：Shopify webhook、CMS 發布或定時工作如何讓相關頁面更新。失效範圍太大會造成重建尖峰，太小又可能留下舊資料。
Cart mutation 要處理 userErrors
建立、加商品、更新數量、buyer identity 和 discount 都可能回傳 user errors 或 warnings。前端應保存 cart ID，處理過期或無效 cart，並避免使用者快速點擊造成重複 mutation。進入付款時使用 cart 的 checkoutUrl，不要自行拼 checkout 路徑。
測試缺貨、數量限制、selling plan 失效、折扣不適用和市場切換。正常加入購物車只覆蓋最簡單的情況。
Bot、Buyer IP 與安全
Public 和 private Storefront token 有不同使用位置。Private token 留在 server，並依 Shopify 指南正確傳遞 buyer IP 等資訊。自動 crawler 若需要存取，評估 Web Bot Auth；不要把一般顧客流量和內部批次爬蟲混在一起。
限制輸入、query 深度和可呼叫操作，監看異常來源。即使 Storefront API 本身承擔平台保護，你的 hosting 和搜尋服務仍可能被大量請求拖累。
把版本與觀測列進估算
固定 API version，記錄升級日程、棄用檢查和 regression tests。監控 request latency、錯誤類型、cache hit、cart mutation failure 與 checkout redirect。Log 不應保存完整 token 或不必要的顧客資料。
估算表最後分成初期 query 與型別、cache 和 revalidation、cart/checkout、錯誤 UX、安全、測試、監控及每季升級。將 inventory 連回 Headless Shopify 架構，才能看出 API 工作和 CMS、搜尋、部署之間的依賴。
每季用 production traces 回顧最慢、錯誤最多和從未使用的 query，讓 API inventory 跟著真實系統更新。