Azure Static Web Apps 搭配後端 API 的實作心得
開頭
如果你手上有一個靜態前端專案，但又需要一點後端能力，例如查詢資料、處理簡單商業邏輯，Azure Static Web Apps 是一條很值得考慮的路線。
這篇筆記整理的是我在 Azure Static Web Apps 免費方案下，搭配 Azure Functions 當後端 API 的實作觀察。重點不是把架構講得很大，而是記下真正上線時會碰到的幾個關鍵限制。
背景
我這次是拿一個 Blazor WebAssembly 測試網站來做實驗，想確認前端部署到 Azure Static Web Apps 之後，能不能順便把 API 一起帶上去。
結果是可以，但不是「把前端丟上去就結束」這麼簡單。實際上還要注意部署流程、專案相依關係，以及免費方案底下的受控模式限制。
說明
1. 免費方案下，API 其實是受控的 Azure Functions
Azure Static Web Apps 的免費方案可以搭配後端 API，但那個 API 不是你平常獨立管理的 Function App，而是由 SWA 受控的 Azure Functions。
這代表幾件事：
- 你不會在 Azure Portal 的 Function Apps 清單裡看到它
- 它比較適合輕量 API
- 如果要做長時間執行、排程或佇列處理，就不太適合放在這裡
2. 部署流程要一起調整，不能只看前端
一開始如果是 Azure 自動產生的部署流程，常常只夠發前端。
但當你把 Function 一起加進來時，workflow 通常還要再調整一次，確保前端和 API 都有被正確發行。參考github workflows yml
3. 專案之間不能互相依賴
當 Function 加進來之後，架構上要保持乾淨分離。
我在這次測試裡特別注意到：
- 前端專案與 Function 專案不能互相相依
TargetFramework要從net48改成net9.0。- Azure Static Web Apps 不支援
.NET 10。
- Azure Static Web Apps 不支援
- 如果目標框架不在 Azure Static Web Apps 支援範圍內，部署就會卡住
這類問題通常不是程式碼本身錯，而是平台與專案結構不合。
4. 免費方案有自己的配額與邊界
Azure Static Web Apps 免費方案可以滿足不少小型專案，但它的邊界也很明確。
我這次整理下來的重點是：
- 適合靜態前端加輕量 API
- 適合快速驗證與個人專案
- 不適合把它當成全能後端平台
如果需求開始碰到較長的工作流程、背景任務或更複雜的後端架構，就該重新評估獨立 Function App 或其他 Azure 服務。
結論
Azure Static Web Apps 很適合做「靜態前端 + 輕量 API」的組合，尤其是你想要一個能快速部署、成本低、維護也不複雜的方案時。
真正的關鍵不在於能不能接後端，而在於你是否接受它的受控模式與平台限制。只要需求落在那個範圍內，它是一條相當實用的路。
