從網頁開發常態說起
要了解 Jamstack 架構解決什麼問題，需要先回顧網頁演變的歷史。
靜態檔案 ～ 伺服器渲染
早期網頁一切都非常簡單，僅須提供靜態的文件供用戶瀏覽，但隨著時間和需求演進，網頁開發者需要「動態生成」頁面中的資料並提交給用戶，也就是伺服器渲染。
- 全天候維運伺服器以即時渲染網頁，不僅資源耗費大，也容易產生效能瓶頸
- 伺服器每次都需要為新內容建構新頁面 (效能差、難快取)
- 傳統 CMS (網站內容管理系統)、資料庫、後端、前端高度耦合相互綑綁
- ⋯⋯
伺服器渲染 ～ 客戶端渲染
隨著工具與環境的成熟，開發者開始將網頁的前後端分離與打造無頭技術，藉由 API 驅動，透過前端框架來渲染資料於瀏覽器，但將渲染的動作全部推給瀏覽器明顯也有對應的缺點，像是：
- SEO 差勁（網路爬蟲無法很好即時渲染頁面）
- 完全依賴 JS 處理網頁渲染（裝置效能問題、加載效率問題）
- ⋯⋯
Jamstack 解決什麼問題？
Jamstack 傳遞靜態網頁並透過串接外部服務增添動態內容，通常事先用靜態生產器(Static Site Generator)預先渲染(Pre-rendering)靜態頁面，並儲存在內容傳遞網路 (CDN) ，再將動態的內容透過串接 Serverless 或分散微服務來實現。
舉實際案例來說，小明製作了一個天氣網站，該網站部署在伺服器上，會根據每次請求即時渲染最新的天氣頁面。雖然大部分內容都是重複的，但伺服器仍需持續運作以產生最新頁面，造成資源浪費。
但假設小明使用 Jamstack 方法來重建該應用，可以先製作一個輕量的前端界面分佈於 CDN 中達成更好的傳輸效益，而動態資料只須透過訪問外部服務獲取即可（重點在於如何處理天氣資料與該 Jamstack 毫無關聯，我們只須在乎 API 拿到對應的結果）。
JavaScript
現代網頁互動的核心，在 Jamstack 中，透過 JavaScript 來加載與展示動態網頁內容的部份。
API
Jamstack 將資料來源與邏輯交付給 API，透過串接第三方服務來取得資料，透過 API 串接的方式來銜接兩者。
Markup
網頁內容預先以靜態方式生成，包含 HTML、CSS 及資產。這些 Markup 可直接部署於 CDN，提升速度與安全性。
總結
單從三個詞並不容易理解它的實際架構與優勢，盡量用一句話描述我會這樣描述：
強調預先生成靜態頁面並解耦商業邏輯與內容，以提高網站效能、彈性與安全性
可以看到像是 Cloudflare、Netlify 與 Vercel 這類開發服務平台也積極的在推動這類架構，帶動 Serverless。
- 簡單的靜態檔案時期
- 動態渲染網頁於伺服端時期
- 靜態渲染網頁於瀏覽器時期
- 靜態渲染網頁 + 透過串接外部服務添加動態內容，Jamstack 時期
你應該使用 Jamstack 的原因
- 安全：內容是盡可能預渲染且分散獨立的，提高攻擊難度。
- 便宜高效：可將 Jamstack 網站分佈於 CDN 上，藉由快取加快內容傳遞與降低成本。
- 易於維護：預渲染頁面只是一堆靜態檔案，理論上十分穩定與方便維護
- 開發體驗：基於廣泛可用的工具和約定，服務與資料是方便動態替換調整的。
你不應該使用 Jamstack 的原因
- 建構時間較長 - 由於所有的頁面都事先在伺服器上渲染出來，過於大量的網頁建構將會花費大量的時間，增量靜態生成(Incremental Static Generation) 通常是該問題的解方。
- 較適合內容變動不頻繁的網站 - 由於 Jamstack 架構的限制，它可能無法滿足某些應用程式的需求。如果需要動態生成大量的頁面，使用其他架構來滿足需求會更為妥當。