Jamstack 是什么
定义
Jamstack 是一种旨在使 Web 更快、更安全且更易于扩展的架构。它建立在许多开发人员喜爱
的工具和工作流程之上，并带来了最大的生产力。
历史
“Jamstack”最初被命名为“JAMstack”，其中“JAM”代表 JavaScript、API 和Markup。
- JavaScript
动态功能由 JavaScript 处理。您必须使用哪个框架或库没有任何限制。比如 React、Vue - APIs
服务器端操作被抽象为可重用的 API，并通过 HTTPS 和 JavaScript 访问。这些可以是第三方
服务或您的自定义功能。比如 Prisma、Auth0、Google Analytics、Elastic Search - Markup
网站以静态 HTML 文件的形式提供。这些可以使用静态站点生成器从源文件（例如
Markdown）生成。比如 Next.js、Hugo、Gatsby - 时间线
2015 年，由于某些 SSG（例如 Jekyll）的流行，静态站点变得越来越流行。
2016 年，一小部分开发人员认为静态站点不必是静态的，因此“Jamstack”一词应运而生。
2017 年，现代网络革命开始优先考虑性能、可扩展性和开发人员体验的重要性。 Jamstack 一
词开始被更广泛的开发人员所采用，并宣布了第一个企业级 Jamstack 项目。
2018 年，Netlify、Gatsby 和 Contentful 等工具帮助推广了该术语，社区正在迅速发展。这
也是第一届 Jamstack 会议的一年。
2019 年，Jamstack 成为主流的那一年。大量新工具和服务进入市场以支持 Jamstack 站点。
2020 年，“JAMstack”成为“Jamstack”，并为社区带来了一个新品牌。随着 Next.js 越来
越受欢迎，ZEIT 变成了 Vercel，并开始模糊 Jamstack 的真正含义，这主要是因为它能够在同
一个站点中结合服务器端和静态渲染。
2021 年，尽管 Jamstack 继续扩展，但对其真正含义的混淆已成为一个共同的主题。然而，像
RedwoodJS 和 Blitz.js 这样的工具向我们展示了 Jamstack 并没有放慢速度。
核心原则
- 预渲染 pre-rendering
Pre-render / Pre-generate
在需要时生成表示视图的标记。这发生在构建期间而不是按需发生，因此 Web 服务器不需要为
收到的每个请求执行此活动。
通过 SSG（Static Site Generators）实现，比如 Next.js - 解耦 decoupling
解耦是在系统或服务之间创建清晰分离的过程。通过分离运营站点所需的服务，每个组成部分都可
以变得更容易理解，可以独立更换或升级，并且可以指定为组织内或第三方的专门专家的权限。
比如使用 Headless CMS，以 API 形式提供数据，供各种端使用
优点
- 更快的性能
通过 CDN 提供预先生成的资源 - 更安全
无需担心服务器或数据库漏洞 - 更低的价格
托管静态文件很便宜，甚至是免费的。 - 更好的开发体验
前端开发人员可以专注于前端，而不受单一架构的束缚。这通常意味着更快、更专注的开发。 - 可扩展
如果用户量激增，CDN 会无缝补偿 - 自动化构建
当需要新构建时，服务器会收到通知，通常是通过 webhook。服务器构建项目，更新 CDN，网站上线。
生态系统
NextJS
一种用于生产环境的 React 框架。Next.js 为您提供生产所需的所有功能的最佳开发人员体验：
混合静态和服务器渲染、TypeScript 支持、智能捆绑、路由预取等。无需配置。
主要特性
- 零配置
自动编译和打包。从一开始就针对生产进行了优化，比如图片优化、字体优化。 - 预渲染：SSG、SSR
在单个项目中的构建时 (SSG) 或请求时 (SSR) 预渲染页面。
https://nextjs.org/docs/basic-features/pages#pre-rendering - 增量静态生成：ISG
在构建时间之后逐步添加和更新静态预渲染页面。
https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration - 支持 TypeScript
类型安全 - 快速刷新
开发效率高 - API Routes
可作为BFF使用
https://nextjs.org/docs/api-routes/introduction
三种渲染模式：CSR、SSR、SSG
CSR
Client Side Rendering
过程
前端请求服务端，客户端收到 html 模板，然后请求 js、css，执行 js 渲染
优点
- 服务器响应快
服务器发送空白页，然后客户端再去请求资源 - 静态化部署
- 支持 SPA
缺点
- 白屏
- 包大
SSR
Server Side Rendering
过程
前端请求服务端，服务端调接口，返回给前端生成的 html 再渲染
优点
- 渲染快
服务端已经生成了 html，客户端直接渲染 - 客户端没有 API 请求
- 理想的 SEO
缺点
- 在服务器上慢
需要请求接口；服务器压力 - UI 兼容性
比如服务端没有 window 对象，存在 UI 适配性问题
SSG
Static Site Generation
过程
服务器构建时调接口，预生成 html，前端请求时收到预生成的资源
优点
- 渲染快
服务端已经生成了 html，客户端直接渲染 - 客户端没有 API 请求
- 理想的 SEO
- 提供服务快
直接托管到 CDN 即可 - 不需要服务端
已经有生成好的 html 了
缺点
- 当内容多时，构建慢
- UI 兼容性
比如服务端没有 window 对象，存在 UI 适配性问题
实践案例
next-one-piece
适用场景
- 有 SEO 需求
- 相对来说不会频繁更新的网站，如电商、博客、官网等
最佳实践
- CDN
由于所有资源都是预先构建，不依赖服务端代码，直接托管到 CDN 上，访问速度快、体验好 - 现代化构建工具
充分利用现代构建工具，如 Babel、PostCSS、Webpack。在今天使用明天的 Web 标准，而无需等待明天的浏览器。 - 原子化部署
每个部署都是站点的完整快照。这有助于保证全球网站的一致版本。 - 缓存失效
上传构建后，CDN 会使其缓存失效。这意味着新的构建会立即生效。 - 版本控制
Git，主要好处是可以查看改变每个文件的历史、合作者和可追溯性。
理想的工作流
推荐阅读
https://jamstack.org/
https://jamstack.wtf/
https://zhuanlan.zhihu.com/p/281085404
https://posts.careerengine.us/p/61077232272a316df461539e
网友评论