从网页开发常态说起
要了解 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 架构的限制，它可能无法满足某些应用程序的需求。如果需要动态生成大量的页面，使用其他架构来满足需求会更为妥当。