自从网络诞生以来，我们使用和构建网络的方式已经发生了巨大的变化。开发人员已经见证了许多旨在满足更复杂的用户体验、支持不断发展的设备功能以及实现更高效的开发工作流程的架构和开发范例的兴起和衰落。
2015 年，Netlify 的创始人 Matt Biilmann 和 Chris Bach 创造了术语“Jamstack”来描述他们所倡导并逐渐流行的架构模型。实际上，这种模型的基础从网络诞生之初就已存在。但多种因素促使他们创造了这个新术语来概括这种方法，并为开发人员和技术架构师提供更好的讨论方式。
在本文中，我将探讨这些因素、Jamstack 的属性、该术语的由来，以及它如何改变我们进行 Web 开发的方式。
什么是 Jamstack？
所有 Jamstack 站点都共享一个核心原则：它们是在构建或编译过程中生成的一组静态资源，因此可以从简化的 Web 服务器或直接从内容分发网络 (CDN) 提供服务。
在“Jamstack”这个术语出现之前，许多人将这些站点描述为“静态的”。这描述了网络上的第一个站点是如何创建的（尽管 CDN 是后来才出现的）。但是，由于工具、服务和浏览器的发展方式，“静态站点”这个术语不足以捕捉 Jamstack 的可能性。
最简单的 Jamstack 站点是作为静态文件提供的单个 HTML 文件。长期以来，开源 Web 服务器有效地托管了这种方式的静态资源。这已经成为一种商品，包括亚马逊、微软和谷歌在内的公司提供的托管服务是基于文件服务，而不是花费计算周期来按需生成每个请求的响应。
但这只是一个静态站点？对吧？
嗯，是的。但这只是开始。Jamstack 在此基础上构建，以交付那些颠覆了“静态”作为有用描述符的站点。
如果你更进一步，在等式中引入 JavaScript，你就可以开始增强用户的体验。现代浏览器拥有越来越强大的 JavaScript 引擎（例如来自 Google 的开源 V8）和强大的浏览器 API，以启用诸如本地缓存、位置服务、身份服务、媒体访问等等服务。
在许多方面，浏览器的 JavaScript 引擎已经取代了在 Web 体验中执行动态操作所需的运行时环境。传统的技术栈，例如 LAMP，需要配置和维护操作系统 (Linux) 和活动 Web 服务器 (Apache)，而这些都不是 Jamstack 需要考虑的。文件以静态方式提供给客户端（浏览器），如果需要任何计算，它可以在那里发生，而不是在托管基础设施上。
正如 Matt Biilmann 所描述的那样，“运行时已经向上移动了一层，移动到了浏览器。”
Web 体验并不总是需要内容是动态的或个性化的，但它们经常需要。Jamstack 站点可以提供这一点，这要归功于 JavaScript 的高效使用以及蓬勃发展的 API 经济。现在许多公司通过 API 提供内容、工具和服务。这些 API 使即使是小型项目团队也能够将以前无法获得的、成本高昂且复杂的功能注入到他们的 Jamstack 项目中。例如，团队无需构建身份验证、支付和履行服务，或托管、维护、保护和扩展数据库功能，而是可以通过 API 从这些领域的专家那里获取这些功能。
企业已经涌现出来，以提供这些和许多其他服务，它们具有使其稳健、高效和可持续的所有规模经济和领域专业化。通过 API 使用这些服务的能力将它们与 Web 应用程序的代码解耦，这是一件非常理想的事情。
因为这些服务使我们超越了旧的静态站点概念，所以需要一个更具描述性的术语。
名称的意义是什么？
现代浏览器中可用的 JavaScript，调用 API，并丰富使用 markup (HTML) 交付的底层站点内容，这些是 Jamstack 名称中的 J、A 和 M。它们标识了允许站点远远超越静态站点的属性，而无需复杂且昂贵的活动托管基础设施。
但是，无论你决定使用所有这些属性还是仅使用其中一些属性，Jamstack 的关键原则是提前创建资产，以大大改进托管和开发工作流程。这是一种从高风险的、即时请求服务方法到简化的、更可预测的、提前准备的方法的转变。
正如 Aaron Swartz 早在 2002 年就简洁地指出，“烘焙，而不是油炸”你的页面。
使用 Jamstack 的 4 个好处
采用这种将资产的生成（或渲染）与资产服务工作解耦的模型创造了重要的机会。
降低扩展成本
在传统的堆栈中，视图是为每个传入的请求生成的，因此流量和服务器上完成的计算工作量之间存在关联。这可能会影响托管堆栈的所有级别，从负载均衡器和 Web 服务器到应用程序服务器和数据库服务器。当配置这些额外的基础设施层以帮助管理负载时，它会增加环境的成本和复杂性，以及操作基础设施和站点本身的工作。
Jamstack 站点扁平化了该堆栈。视图的生成工作仅在代码或内容更改时发生，而不是为每个请求发生。因此，可以提前准备站点并直接从 CDN 托管，而无需动态执行昂贵的计算。大型基础设施（以及与之相关的工作）消失了。
简而言之：Jamstack 站点默认情况下针对扩展进行了优化。
提高速度
传统上，为了提高托管基础设施的响应时间，那些有预算和技能的人会添加 CDN。识别可能被认为是“静态”的资产并将这些资源的提供卸载到 CDN 可以减少 Web 服务基础设施的负载。因此，某些请求可以从针对该任务优化的 CDN 更快地提供服务。
使用 Jamstack 站点，整个站点都从 CDN 提供服务。这避免了确定哪些必须动态提供服务以及哪些可以从 CDN 提供服务的复杂逻辑。
每次部署都变成更新 CDN 上整个站点的操作，而不是跨多个基础设施。这允许你自动化该过程，从而可以提高你对部署站点更新的信心，并降低成本和摩擦。
降低安全风险
删除托管基础设施，特别是那些基于接收到的请求进行计算的服务器，对站点的安全状况产生深远的影响。Jamstack 站点比传统站点具有更少的攻击面，因为不再需要许多服务器。没有比不存在的服务器更安全的服务器了。
CDN 基础设施仍然存在，但经过优化以提供预生成的资产。由于这些是只读操作，因此它们被攻击的机会更少。
增强工作流程
通过从站点托管中删除如此多的活动部件，你可以极大地改进开发和部署它们所涉及的工作流程。
Jamstack 站点支持端到端的版本控制，并且通常使用 Git 和 Git 约定来执行从定义和配置新环境到执行部署的所有操作。部署不再需要更改多个托管基础设施的状态、资源或配置。并且它们可以在本地、暂存环境和生产环境中轻松测试。
这种方法还允许更全面的项目封装。站点的代码仓库可以包含引导项目所需的一切，包括定义构建站点所涉及的依赖项和操作。这简化了开发人员的入职和走向生产的路径。（这是一个示例。）
面向所有人的 Jamstack
熟悉各种工具和框架的 Web 开发人员正在拥抱 Jamstack。他们正在实现新的生产力水平，这得益于他们认识到可以使用许多工具和语言，这些工具和语言将更多的权力和能力掌握在他们手中。
在开发社区中具有高采用率和喜爱度的开源库和框架正在与第三方和第一方 API 结合使用，以产生功能强大的解决方案。低门槛意味着它们更容易探索，从而提高开发人员的自主权、效率和热情。
评论已关闭。