Jamstack介绍 (Next.js)

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 支持、智能捆绑、路由预取等。无需配置。

主要特性

三种渲染模式: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

Incremental Static Regeneration (ISR)

在以上例子中,Next.js 在构建阶段请求mock接口,获取了 2 条数据,预渲染了 2 个页面的资源(dahe 和 lufei)。

https://github.com/js-fu/next-one-piece/blob/main/pages/ssg/detail/%5Bname%5D.tsx#L26

[{
    "name": "lufei",
    "nameCn": "路飞",
    "img": "/img/lufei.jpeg",
    "devilFruit": "橡胶果实(人人果实幻兽种尼卡形态)"
  },
  {
    "name": "dahe",
    "nameCn": "大和",
    "img": "/img/dahe.png",
    "devilFruit": "动物系幻兽种“犬犬果实·大口真神形态”"
  },
  {
    "name": "qiaoba",
    "nameCn": "乔巴",
    "img": "/img/qiaoba.webp",
    "devilFruit": "动物系“人人果实”",
    "deleted": 1
  }
]

修改mock接口数据,把qiaoba的deleted改成了0,并访问qiaoba的ssg详情页(http://localhost:3000/ssg/detail/qiaoba)后,构建产物页新增了qiaoba的静态资源。

然后再把qiaoba的deleted改成了1,经过配置的10秒过期时间,再访问qiaoba的ssg详情页,qiaoba的静态资源再次变化,变成not found。

适用场景

  • 有 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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容