JAMStack，构建下一代 Web 应用
JAM Stack 中的 JAM 其实是三个词的缩写，它们分别是J avaScript, A PIs 以及M arkup，而 Stack 就是技术栈（Tech Stack），也就是我们在构建应用的时候具体使用到的技术的集合。
JAMStack 是一种用来构建更快、更安全、更易扩展（scale）网站的架构 ，其是一种问题解决方案 ，而不是一个具体的实现。
Why JAMStack
在传统架构，如 WordPress 中，用户访问时，由服务端处理、生成 HTML 页面并返回给浏览器，需要大量的后端、运维人员维护网站的安全性、稳定性、可伸缩性。
在 JAMStack 架构下，用户直接就近访问部署在 CDN 中的静态页面以及 API 服务，无需自建服务，开发者仅需构建、维护 JAMStack 应用。比传统架构响应速度更快，更稳定，更易扩展。
从上面的架构来看，JAMStack 与静态网站十分类似，事实上也的确如此。从本质上来说，JAMStack 就是结合了静态网站 + API 的增强版本，即部分静态，部分动态。
优点
JAMStack 应用通常具有如下的优点
-
高性能：多数为静态的网页，基于 CDN 分发内容，很少有额外的数据请求
-
更安全：使用 API 服务，无需关心服务和数据库
-
更低的成本：只需静态托管的费用和少量的 API 请求费用
-
更稳定：CDN 服务通常比较稳定，相比 Web Server 更不容易出现问题
-
更好的开发体验：前端单独开发、单独部署、单独测试，完全解耦后端架构
核心
预渲染
通过网站生成器，生成经过高度优化的静态文件，直接部署到 CDN 上，使得网站的安全性，访问速度，扩展性得到了最大程度的优化。
这样的网站生成器，包括但不限于 Gatsby、Hugo、Jekyll、Eleventy、NextJS…
使用 JavaScript 增强体验
在网站访问体验良好的情况下，可以使用 JavaScript 结合服务 API，实现更多的功能，增强用户体验。不限定具体的框架或库，常用的库包含 React，Vue，Angular 等
使用 API 服务增强网站功能
服务端操作可以抽象为 API 调用，可能是第三方或者自定义服务，如云函数等。可以更多地利用第三方服务快速实现网站的能力，而不是自己花精力实现，如身份认证、支付、内容管理、数据服务、搜索等。
JAMStack Workflow
一个简单的 JAMStack 网站构建流程
-
开发者编写网站代码，使用 API 增强网站功能
-
推送代码，触发 CI 构建，或定时构建
-
CI 构建时，自动拉取 CMS/DB 中的数据，生成网站
-
部署到网站托管或 CDN 服务中
变革
这里可以看到，部署一个 JAMStack 站点是非常容易的。在 CI 自动化等特性的加持下，部署一个站点只需要点几下按钮，等待几分钟即可完成，这对前端的开发测试流程带来了革命性的变化。
得益于 JAMStack 宜部署的特性，在开发、测试、产品体验等流程中，只需要针对不同的特性部署生成不同的 URL 即可：
-
产品、设计同学想体验新的特性，部署一个 URL
-
产品测试，测试同学可以部署生成自己独立的 URL
-
开发、测试、预览等不同的环境拥有独立的 URL
-
代码分支合并，可以为新的分支生成预览 URL，直接查看实际效果
-
…
毫无疑问，JAMStack Wokrflow 宜部署的特性具有极大的想象空间，带来了许多变革。不再需要配置各种 Host，各种代理，解决复杂的网络问题，可以把精力投入到开发上，极大的简化、加快了产品研发的流程。
问题
JAMStack 有很多优点，但是 JAMStack 也不是完美无缺的，它仍然存在一些问题。
通常情况下，通过 CMS 更新 JAMStack 站点内容时，需要重新进行整站构建，当内容较多时，构建会花费较多时间，而内容数量达到数万或更多时，构建生成静态内容可能不是个好的选择。
比如，假设一个电商网站有十万件商品，需要生成十万个左右的静态页面，为每个商品的介绍页面。这时，构建生成十万个静态页面的耗时会很长，网站内容变动带来的更新压力也会很大。
总得来说，并不是所有应用都适合静态化，不过这仍然是一个不错误优化选择。
工具
常用的 SSG/SSR 框架
-
Next：基于 React 的 SSR 框架
-
Nuxt：基于 Vue 的 SSR 框架
-
Gatsby：基于 React 的 SSG 解决方案
-
Gridsome：基于 Vue 的 JAMStack 框架
一些 JAMStack 的全栈解决方案
Web 托管服务
总结
JAMStack 本质上是一种构建增强的静态网站 的技术，在某些场景下会有不错的表现。
不必拘泥于教条定义，能够灵活地使用各种技术解又快又好地决实际遇到的问题才是关键。