Jamstack的演变

自从我在2016年旧金山的SmashingConf举行了Jamstack建筑以来，已经五年了，这是一个与业内同事和朋友的许多谈话启发的谈话。此时，从后端业务逻辑层从根本上解耦前端Web层的想法只是早期趋势，尚未成为一个名为架构方法。

静态站点生成器被涌现为构建较大的内容驱动网站的实际选择，但周围的整个生态系统都已加注，主发电机是纯开源工具，没有商业存在。单页应用是一些大型Web应用程序的基础，如Gmail，但建立它们的典型方法仍然是以后代为中心的。

快进到2020年，Jamstack击中了主流，我们看到了数百万个开发商和大型品牌，如联合利华，耐克和PayPal拥抱了架构。像Covid跟踪项目这样的重要举措能够在Jamstack上从0到200万API请求中扩展。蜜蜂等框架成为商业企业，我们庆祝了Microsoft和CloudFlare等大型公共公司，因为他们推出了早期的Jamstack产品。

随着商业空间的加热，开发商社区已经成长，噪音也有更多的噪音，我们甚至开始测试Jamstack最佳实践的界限。它感觉就像在revisit的正确时间，这是我们有些五年前的原来的愿景，并展望了技术景观的变化意味着夹纸架构和网络的未来。

让我们从快速重新审视使​​架构的核心原则转到流行的核心原则。

在Jamstack架构中，编译UI。目标是在正确的时间做正确的工作 - 偏好提前尽可能多地工作。很多次，整个网站可以是预先生的，也许甚至不需要一旦部署后端。

从后端服务和平台解耦的前端强制执行明确的合同，了解您的UI如何与系统的其余部分通信。这默认为简单性：前端具有有限的接触面，在外部外部有任何内容，使其更复杂地了解外部更改将如何影响其操作。

当然，并非一切都可以是预先的，并且Jamstack架构能够提供动态，个性化的Web应用程序以及更多全球一致的内容。请求来自前端的数据可以为一些丰富和动态的应用程序提供电量。

一个很好的例子是我们自己的netlify ui的前端，它本身就是在NetWify上构建和运行的Jamstack应用程序。我们预先编译App shell，然后使用异步请求来点击我们的API以加载有关用户及其站点的数据。无论您是使用REST，GraphQL还是WebSockets，如果您正在向您的UI尽可能多的UI，并加载数据以为用户提供动态，定制的体验，那么您正在运送Jamstack架构。

在Jamstack生态系统上发生了更多的创新，而不是以前发生过。您可以看到后端服务，开发人员工具和客户端技术的快速演变，这些技术与开发团队能够为网络构建体验，这些产品似乎只有几年前似乎遥不可及。

我想指向三个趋势，我看到在不久的将来为Jamstack开发人员塑造：

不仅仅是什么，Jamstack的固有简单性已经使建筑和部署Web应用程序更容易理解。代码和内容更新可以预先渲染为干净的原子部署，并将右侧推向边缘，在无需管理复杂的基础架构的情况下创建强度保证。

但是预渲染了一个较大的网站也可能意味着每次都有几分钟的时间等待新部署。这就是为什么我认为我们看到这么多的创新发生，使得建立更聪明，更快 - 特别是对于较大的网站和网络应用程序。以eSBuild的原始速度，新的“极快的JavaScript编译器”。可以通过eSbuild在一秒钟内完成可能在一分钟内完成包裹或网客的生产捆绑包。并在vite和snowpack等工具上依靠天然的es模块来制作局部发展觉得几乎瞬间。

在反应生态系统中，一些较新的框架像混音或闪电声一样开始倾向于“在服务器上运行一切”的方法，我们在过去都是所有人。有一种冒着我们曾经逃脱的复杂性的风险。缓存层可以帮助让服务器端应用程序更加表现，但开发人员会失去原子部署的保证，使Jamstack应用程序易于理解。

Blitz似乎将整料搬入前端。这可以使全堆叠应用程序在典型的Jamstack平台上运行，但在Web体验层和后端业务逻辑层之间没有任何清晰的解耦。我认为将前端解耦是Jamstack方法的基础，负责解锁这么多的好处。

我看到的真实势头是下一个“混合”框架，如下一个.js，nuxt.js和sveltekit，允许开发人员在构建时使用通过无服务器函数呈现的其他路由来无缝混合使用的页面。挑战是无服务器功能（虽然肯定可扩展）具有自己的一组性能影响。

最终，我看到社区朝着一个极其强大的三重奏移动，提供Jamstack开发人员请求级别控制任何网站或应用程序的性能配置文件：

Next.js在增量静态再生的概念上做了很多工作。该想法是通过在重新验证时使用不同的缓存策略来验证无服务器函数来确保高性能页面。虽然将一些构建分发到仍然包含强大的缓存保证的按需方法的想法是一种强大的技术，除非开发人员明确退出陈旧的态度方法，否则原子部署保证将由服务违反来自不同部署的陈旧和新资产的混合。目前，ISR的好处也是一个单数框架，只能深入融入一个提供商的产品。

在NetLify，我们在允许开发人员在构建时呈现关键页面的想法，我们看到了很多承诺，同时推迟其他页面（例如旧博客文章，例如）仅在请求时建造。我们称之为分布式持久渲染或DPR的方法。它是一个增量构建的架构，可以在几乎每个框架和jamstack站点生成器中兼容，从11t0到nuxt到next.js.

DPR将大大减少较大网站的前期建设时间，解决对静态站点的核心批评。在jamstack.org上，我们开设了评论要求，让整个社区涉及我们的努力，让开发人员提供更多选择页面的何种选择，同时遵守符合Jamstack如此受欢迎的原则。通过将此体系结构提供一个名称和完善的社区输入，我们可以帮助Jamstack开发人员构建它周围的模式 - 无论框架如何。

如果您开发Web应用程序，您可能遵循状态管理库的演变，因为开发人员使用React，Vue和Svelte等工具建立了越来越复杂的Web接口。但国家管理层在很大程度上是浏览器和内存中的关注。每个浏览器选项卡本质上都有自己的状态，但可以非常复杂地将应用程序的本地浏览器状态连接回电源的数据服务。

幸运的是，随着越来越多的服务现在支持实时数据订阅。 Hasura，OneGraph和Sumabase所有这些功能都提供此功能，我只希望在所有提供商中看到宽泛的采用，因为底层数据存储缓存并分发到边缘以进行快速全局性能。拍摄Twillio的扩展API：现在它们不仅提供流式视频，还提供流式传输的“数据轨道”，它可以用于创建在参与者之间保持不断同步的复杂协作应用程序。

最后，新的提供商正在涌现在后端服务中聚合数据。无论您是否使用GraphQL作为查询语言，它真的很引人注目地想象将UI连接到单个底层API的单个标准更新流。

Jamstack建立在GIT工作流程上 - 这是一种对更大的开发团队来说非常良好的方法。但前进，我们将开始了解传统上开发者的专注工具将扩展如何涉及整个公司的每个人：开发人员，肯定，还有作家，编辑，设计师和SEO专家。

当您想到协作时，您倾向于考虑同步编辑 - 例如，飞行Google Doc的多个游标。我们看到现场合作风格来到CMS工具，如Sancy和Design Tools，如Figma。但是，如此多的工作经常发生异步，而非开发人员传统上没有享受开发人员对无缝分支，阶段和合并改变的强大工具，并在每个拉出请求上附加的协作讨论。

在JAMStack早期，一些基于聪明的Git的CMS工具可以帮助非开发人员管理像代码一样的内容 - 也许甚至不知道他们所做的每次更改都像从终端工作的开发人员那样被提交。我们现在开始看到新的工具以与Gatsby和Next.js等流行的Jamstack站点生成器保持兼容的方式，以便仍然兼容。所有这些都会降低对非开发人员合作的栏，我们只会看到趋势加速。

它不仅是非开发人员在协作中加入：工具之间的深度集成在我们的开发，构建和部署工作流程将更多自动化贡献。只需浏览GitHub Pull请求的注释历史记录，以了解现在集成的工具以在部署之前运行自动测试并捕获错误。

例如，对NetLify的Docs的更新不仅仅是针对我们的代码标准而闻名，他们也针对我们的内容标准暗示，确保我们保持与我们的词汇，语言和措辞的风格指南一致。团队现在也可以轻松地将性能预算和SEO标准与每部部署重新连接到直接与GitHub问题中的警报和日志。

我希望看到那些集成在来年爆炸，允许基于Git的工作流到不仅仅是代码更改，还可以在内容中进行内容，而且还包括内容，数据，设计资产 - 您展示它。 友好的接口进入这些Git工作流程将允许更多贡献者来评论，提交和协作并将开发人员生产力工具进一步进入主流。 虽然Jamstack符合从后端解耦和维护不可改变的和原子部署的前端的核心概念，但新的构建策略和计算原语具有潜力可以解锁极大的大规模站点和动态实时Web应用程序。 Jamstack开发人员 - 现在整个Web团队，营销人员和产品经理 - 在这个空间中有很多期待。